hotlogin-mcp

Server Quality Checklist

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

Latest release: v1.0.3
Disambiguation5/5
Each tool has a clearly distinct purpose with no ambiguity. Tools are organized by resource type (env, group, proxy, health) and specific actions (create, query, remove, revise, etc.), making it easy for an agent to select the right tool without confusion.
Naming Consistency5/5
Tool names follow a highly consistent pattern throughout: resource_action format (e.g., env_create, group_query, proxy_remove). All tools use snake_case with no deviations, and verbs are standardized across resources, ensuring predictable naming.
Tool Count4/5
With 23 tools, the count is slightly high but reasonable for the server's scope of managing environments, groups, and proxies. Each tool appears to earn its place by covering specific operations, though it may feel heavy compared to simpler servers.
Completeness5/5
The tool surface provides complete CRUD/lifecycle coverage for environments, groups, and proxies, including additional operations like launching, terminating, and checking health. There are no obvious gaps, and agents can handle full workflows without dead ends.
Average 2.2/5 across 23 of 23 tools scored. Lowest: 1.3/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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. '创建环境' reveals nothing about whether this is a read or write operation, what permissions are required, whether it's idempotent, what happens on success/failure, rate limits, or side effects. For a complex creation tool with 8 parameters, this complete lack of behavioral context is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just two characters, this is under-specification rather than effective brevity. The description fails to communicate essential information about a complex tool, making it inefficient for an AI agent that needs to understand when and how to invoke it. Every sentence should earn its place, but here there's essentially no sentence at all.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity (8 parameters with nested objects), zero annotation coverage, and no output schema, the description is completely inadequate. It provides no information about what an 'environment' represents in this system, what happens after creation, what values are returned, or how this integrates with other tools. The description fails to compensate for the lack of structured metadata.
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?
With 0% schema description coverage and 8 complex parameters (including nested objects for proxy configuration, account info, fingerprint, and advanced settings), the description adds zero semantic information about any parameters. It doesn't mention that 'name', 'groupId', 'remark', 'proxyId', 'accountInfo', 'fingerprint', or 'advancedSetting' are even expected, let alone explain their purposes or relationships.
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 '创建环境' (create environment) is a tautology that restates the tool name 'env_create' without adding specificity. It doesn't clarify what type of environment is being created, what resources are involved, or how this differs from sibling tools like 'group_create' or 'env_revise'. While it contains a verb ('创建'), it lacks meaningful differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. With multiple sibling tools like 'env_revise' (modify), 'env_remove' (delete), 'group_create' (create group), and 'env_launch' (launch environment), there's no indication of prerequisites, appropriate contexts, or distinctions between creation and other operations.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails completely. '启动环境' gives no indication of whether this is a read or write operation, what permissions might be required, whether it's destructive, what side effects occur, or what the expected behavior is. For a tool with 7 parameters and no output schema, this lack of behavioral information is critically inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just two characters, this represents under-specification rather than effective brevity. The description doesn't earn its place - it provides no useful information beyond what's already in the tool name. For a complex tool with 7 parameters, this level of conciseness is inadequate and unhelpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no annotations, no output schema, multiple sibling tools), the description is completely inadequate. It provides no information about what the tool does, when to use it, what parameters mean, what behavior to expect, or what results are returned. The agent would be operating blindly with this tool, unable to make informed decisions about its invocation.
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?
With 7 parameters and 0% schema description coverage, the description provides zero information about any parameters. The schema shows parameters like 'id', 'number', 'openIpTab', 'startUpParam', 'headless', 'skipProxyCheck', and 'timeout', but the description doesn't mention any of them, explain their purposes, or provide context about how they affect the environment launch. This leaves all parameters completely undocumented.
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 '启动环境' (launch environment) is a tautology that essentially restates the tool name 'env_launch'. It provides no specific verb-resource combination, doesn't explain what 'environment' means in this context, and doesn't distinguish this tool from sibling tools like env_create, env_opened, or env_terminate. The purpose remains vague and unhelpful for an agent trying to understand when to use this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. With multiple sibling tools related to environments (env_create, env_opened, env_terminate, env_query, etc.), there's no indication whether this launches existing environments, creates new ones, or performs some specific type of environment initialization. The agent receives no context about prerequisites, appropriate scenarios, or tool selection criteria.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. '创建分组' only indicates a creation action but reveals nothing about permissions required, whether the operation is idempotent, what happens on failure, whether there are rate limits, or what the expected response looks like. For a mutation tool with zero annotation coverage, this is completely inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with only two Chinese characters, this is a case of harmful under-specification rather than effective brevity. The description is too terse to be useful - it doesn't provide enough information for an AI agent to understand when and how to use this tool. Every sentence should earn its place, but this description doesn't earn its place by being informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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, no output schema, and 2 parameters with 0% schema coverage, the description is completely inadequate. It doesn't explain what the tool does beyond the obvious, provides no behavioral context, no parameter guidance, and no differentiation from similar tools. For a creation operation that likely has side effects, this leaves the agent guessing about important implementation details.
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?
With 0% schema description coverage and 2 parameters (name, remark), the description provides zero information about parameter meaning, format, constraints, or usage. The schema shows 'name' is required and 'remark' is optional, but the description doesn't explain what constitutes a valid group name, what remarks are for, or any parameter relationships. This fails to compensate for the complete lack of schema documentation.
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 '创建分组' (create group) is a tautology that restates the tool name 'group_create' in Chinese. It provides no additional specificity about what kind of group is being created, what system it belongs to, or how it differs from sibling tools like 'env_create' or 'proxy_create'. While the verb 'create' is clear, the resource 'group' is too vague without context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. There are multiple creation tools in the sibling list (env_create, proxy_create), but no indication of what distinguishes group creation from environment or proxy creation. No prerequisites, constraints, or appropriate contexts are mentioned.
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 the full burden of behavioral disclosure. '创建代理' (create proxy) implies a write/mutation operation, but the description doesn't disclose any behavioral traits such as authentication requirements, side effects, rate limits, or what happens upon successful creation. It fails to provide any context 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two Chinese characters, which could be seen as efficient. However, this brevity comes at the cost of being under-specified rather than appropriately sized. It's front-loaded in the sense that there's nothing else, but it fails to provide necessary context for a tool with 12 parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (12 parameters, 0% schema description coverage, no annotations, no output schema), the description is completely inadequate. It doesn't explain the purpose, usage, behavior, or parameters, leaving the agent with insufficient information to understand or invoke this tool correctly. For a creation tool with many parameters, this level of description is insufficient.
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?
The description provides no information about any of the 12 parameters. Schema description coverage is 0%, meaning none of the parameters have descriptions in the schema. The description doesn't compensate by explaining what parameters like 'address', 'port', 'type', 'agentGroupName', or others mean, leaving the agent with no semantic understanding of the inputs required.
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 '创建代理' (create proxy) restates the tool name 'proxy_create' in Chinese, making it a tautology. It doesn't specify what kind of proxy is being created or what resources are involved. While it indicates a creation action, it lacks the specificity needed to distinguish it from sibling tools like proxy_query, proxy_remove, or proxy_revise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 for proxy management (proxy_query, proxy_remove, proxy_revise), but the description doesn't indicate that this is specifically for creating new proxies versus querying, removing, or revising existing ones. No context 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.
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 but provides none. It doesn't indicate whether this is a read-only or destructive operation, what permissions are required, whether it's idempotent, what happens on failure, or any rate limits. For a tool with 13 parameters that appears to modify proxy configurations, this lack of behavioral information is critically inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (just two Chinese characters), but this represents under-specification rather than effective brevity. While it's technically front-loaded with the only information provided, it fails to convey necessary information about a complex tool. The structure is minimal but not helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex mutation tool with 13 parameters, 0% schema description coverage, no annotations, and no output schema, the description is completely inadequate. It provides no information about what the tool actually does beyond the basic verb, no behavioral context, no parameter guidance, and no usage instructions. The agent would struggle significantly to use this tool correctly.
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?
With 0% schema description coverage and 13 parameters (only 2 with enums), the description provides zero information about any parameters. It doesn't explain what 'id' refers to, what the various proxy configuration fields mean, or how parameters interact. The agent must guess parameter meanings entirely from property names, which is insufficient for a complex tool with many configuration options.
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 '更新代理' (Update proxy) is a tautology that merely restates the tool name 'proxy_revise' (proxy revise/update). It doesn't specify what aspects of a proxy are updated, what resources are affected, or how this differs from sibling tools like proxy_create or proxy_remove. The description provides minimal information beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. There's no mention of prerequisites, when this tool is appropriate versus proxy_create or proxy_remove, or what conditions must be met before invoking it. The agent must infer usage entirely from the tool name and schema.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers none. '更新环境' implies a mutation operation but doesn't specify whether this is a partial or complete update, what permissions are required, whether changes are reversible, what happens to unspecified fields, or what the response contains. For a complex 10-parameter mutation tool with nested objects, this is critically 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 at just two characters, with zero wasted words. While this represents severe under-specification rather than ideal conciseness, technically it meets the criteria of being front-loaded and having no unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters with nested objects, no annotations, no output schema, and 0% schema description coverage), the description is completely inadequate. It provides no meaningful context about what the tool does, how to use it, what parameters mean, or what behavior to expect. This is particularly problematic for a mutation tool with extensive configuration options.
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?
The schema has 0% description coverage, meaning all 10 parameters and their complex nested structures are undocumented. The description '更新环境' provides no information about any parameters, their purposes, or how they relate to environment updates. It fails completely to compensate for the schema's lack of documentation.
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 '更新环境' (Update environment) is a tautology that merely restates the tool name 'env_revise' (environment revise). It lacks specificity about what 'environment' refers to in this context or what aspects are being updated. While it indicates a mutation operation, it doesn't distinguish this tool from sibling tools like 'env_create' or 'group_revise'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 modify environments (env_create, env_remove, env_transfer_group, group_revise) and related operations, but the description offers no context about prerequisites, appropriate use cases, or when to choose this specific update tool over others.
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 the full burden of behavioral disclosure. '删除分组' (delete group) implies a destructive mutation, but the description doesn't disclose any behavioral traits: no information about permissions required, whether deletion is permanent or reversible, what happens to associated resources, error conditions, or rate limits. This is inadequate for a destructive operation 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 extremely concise - just two characters in Chinese. While this may be too brief for effective tool selection, it's not verbose or poorly structured. Every character serves the purpose of stating the tool's action, making it maximally efficient in terms of word count.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations, 1 undocumented parameter, and no output schema, the description is completely inadequate. It doesn't explain what the tool does beyond the basic verb, provides no parameter guidance, no behavioral context, and no usage guidelines. This leaves the agent with insufficient information to use the tool correctly.
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?
The schema has 1 parameter with 0% description coverage. The description provides no information about the 'ids' parameter - it doesn't explain what these IDs represent, their format, whether they're group IDs, how to obtain them, or any constraints. The description fails to compensate for the complete lack of schema documentation.
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 '删除分组' (delete group) states the action and resource, which is better than a tautology. However, it's vague about scope - it doesn't specify whether this deletes a single group or multiple groups, nor does it distinguish it from sibling tools like 'env_remove' or 'proxy_remove'. The description provides basic purpose 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 Guidelines1/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 'remove' tools in the sibling list (env_remove, proxy_remove), but the description doesn't explain when to use group_remove specifically. No prerequisites, exclusions, or alternative tools are mentioned.
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 the full burden of behavioral disclosure. '更新分组' (update group) implies a mutation operation, but it doesn't disclose any behavioral traits such as required permissions, whether changes are reversible, potential side effects, or error conditions. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two characters ('更新分组'), which is front-loaded but under-specified. While brevity is good, this lacks necessary detail for a mutation tool. It doesn't waste words, but it also fails to provide essential information, making it inefficient in terms of utility per character.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mutation tool updating groups), lack of annotations, no output schema, and low schema coverage (0%), the description is highly incomplete. It doesn't explain what the tool does beyond the basic action, provide parameter details, describe outcomes, or differentiate from siblings. This is inadequate for a 3-parameter tool with potential side effects.
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?
The description adds no meaning beyond what the input schema provides. With 3 parameters (id, name, remark) and 0% schema description coverage, the schema only indicates types and requirements. The description doesn't explain what these parameters represent (e.g., id for identifying the group, name for the new name, remark for optional notes), leaving their semantics entirely undocumented.
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 '更新分组' (update group) is a tautology that essentially restates the tool name 'group_revise' (group revise/update). While it indicates the action is updating a group, it doesn't specify what aspects of a group are updated or how this differs from other group-related tools like 'group_create' or 'group_remove'. The purpose is vague beyond the basic verb-noun pairing.
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 'group_create', 'group_query', 'group_remove', and 'env_revise' (which might update environment groups), there's no indication of prerequisites, appropriate contexts, or exclusions. The agent must infer usage from the name alone.
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. '删除代理' implies a destructive mutation but provides no information about permissions required, whether deletion is permanent or reversible, rate limits, error conditions, or what happens to associated resources. For a destructive tool with zero annotation coverage, this is completely inadequate.
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 maximally concise at just two characters. While this represents severe under-specification, it's not verbose or poorly structured. Every character earns its place by conveying the core action, though it fails to provide necessary additional information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a destructive mutation tool with no annotations, no output schema, and 0% schema description coverage. The description provides only the bare minimum action without explaining parameters, behavior, consequences, or alternatives. For a tool that permanently removes resources, this level of documentation is dangerously incomplete and could lead to incorrect usage.
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. The description mentions nothing about the 'ids' parameter - what format the IDs should be, where to get them, whether they're proxy IDs or something else, or what happens if invalid IDs are provided. With one required parameter completely undocumented in both schema and description, this represents a significant gap.
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 '删除代理' (delete proxy) is a tautology that restates the tool name 'proxy_remove' in Chinese. It provides a verb+resource but lacks specificity about what kind of proxy is being deleted or how the deletion works. It doesn't distinguish from sibling tools like 'env_remove' or 'group_remove' which perform similar deletion operations on different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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, when deletion is appropriate, or what happens after deletion. With sibling tools like 'proxy_query' and 'proxy_revise' available, there's no indication of when deletion is preferred over revision or what context warrants this destructive operation.
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 '关闭环境' (terminate environment), which implies a destructive operation but doesn't specify critical details: whether termination is irreversible, what permissions are required, if there are side effects (e.g., data loss), rate limits, or error conditions. This is inadequate for a tool with likely significant consequences.
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 just two characters ('关闭环境'), which is front-loaded and wastes no words. For a simple verb-noun phrase, this is appropriately sized, though it may be overly terse given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool likely involves destructive operations (termination), no annotations, no output schema, and 0% schema coverage, the description is severely incomplete. It doesn't cover behavioral aspects, parameter meanings, return values, or usage context, making it inadequate for safe and effective tool invocation.
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%, and the description provides no information about parameters. The input schema has two parameters ('id' and 'number'), but the description doesn't explain what they represent, how they're used (e.g., to identify the environment), or if both are required. With no parameter details in the description, it fails to compensate for the lack of schema documentation.
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 '关闭环境' (terminate environment) states a basic action but lacks specificity about what 'environment' refers to in this context. It distinguishes from siblings like 'env_create' or 'env_launch' by indicating termination rather than creation or launching, but doesn't clarify what resources are affected or the scope of termination compared to similar tools like 'env_terminate_all'.
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. It doesn't mention prerequisites (e.g., environment must exist), exclusions (e.g., cannot terminate running environments), or comparisons to siblings like 'env_terminate_all' (for bulk termination) or 'env_remove' (which might differ in function). The description implies a termination action but offers no contextual usage rules.
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 ('获取' - get) without revealing any traits like read-only vs. mutative nature, permission requirements, rate limits, or response format. This is inadequate for a tool with parameters and no output schema, failing to inform the agent of 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 phrase ('获取环境运行状态') that is front-loaded and wastes no words. It directly conveys the core action without unnecessary elaboration, making it highly concise and well-structured for its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters, no annotations, no output schema), the description is incomplete. It fails to explain what 'runtime state' includes, how parameters are used, or what the tool returns, leaving critical gaps for the agent to understand and use the tool effectively in context with siblings.
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?
The description adds no meaning beyond the input schema, which has 0% coverage (no descriptions for 'id' or 'number'). With two parameters undocumented in both schema and description, the agent lacks essential context on what these parameters represent (e.g., environment ID, instance number) or how they affect the tool's function, severely hindering correct invocation.
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 '获取环境运行状态' (Get environment runtime state) states a clear verb ('获取' - get) and resource ('环境运行状态' - environment runtime state), establishing basic purpose. However, it lacks specificity about what 'runtime state' entails (e.g., metrics, status, health) and does not differentiate from siblings like 'env_query' or 'health_check', making it 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?
No guidance is provided on when to use this tool versus alternatives such as 'env_query' (which might query environment details) or 'health_check' (which might check system health). The description implies usage for monitoring but offers no explicit context, prerequisites, or exclusions, leaving the agent to infer 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 but only states it's a paginated query. It doesn't disclose whether this is read-only (implied but not stated), what authentication is needed, rate limits, what happens with invalid parameters, or the format of returned data. For a query tool with 9 parameters, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (4 Chinese characters) and front-loaded with the core functionality. While efficient, it may be too brief given the tool's complexity. Every word earns its place, but more context might be warranted.
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 has 9 parameters with 0% schema coverage, no annotations, no output schema, and multiple sibling tools, the description is insufficient. It doesn't explain the query's purpose beyond basic pagination, parameter usage, or how results are structured, leaving the agent with inadequate context for proper tool selection and invocation.
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 but provides no parameter information. With 9 parameters (page, size, id, number, groupId, name, remark, proxyId, platform), the description doesn't explain what these filter fields mean, their relationships, or how they affect the paginated query results.
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 '分页查询环境列表' (Paginated query of environment list) states the verb (query) and resource (environment list) with pagination scope, which is adequate. However, it doesn't differentiate from sibling tools like 'env_query' vs 'group_query' or 'proxy_query', leaving ambiguity about what specifically distinguishes this environment query from other query tools.
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 siblings like 'env_profile', 'env_runtime_state', and 'env_opened' that might provide different environment-related data, the description lacks context about when this paginated list query is appropriate versus more specific environment 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 implies a mutation ('organize'), suggesting potential changes to window layouts, but doesn't disclose behavioral traits such as whether it requires specific permissions, if changes are reversible, what happens to existing layouts, or any rate limits. The description is too minimal to provide adequate transparency for a tool with parameters.
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 phrase, which is appropriately concise and front-loaded. There's no wasted text, but it may be overly brief given the tool's complexity. Every word contributes to the purpose, though more detail could improve 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 the tool's complexity (3 parameters with nested objects, no output schema, and no annotations), the description is incomplete. It doesn't cover parameter meanings, behavioral aspects, or usage context. For a tool that likely modifies window layouts, this minimal description is inadequate 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.
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. It mentions 'environment window layout' but doesn't explain the three parameters (auto, mode, config) or their nested properties (e.g., xStart, cols). No semantic details are added beyond the schema's structure, leaving parameters largely undocumented.
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 '整理环境窗口布局' (organize environment window layout) states a general purpose but lacks specificity. It indicates a verb ('organize') and resource ('environment window layout'), but doesn't clarify what 'organize' entails (e.g., arranging, resizing, positioning) or distinguish it from sibling tools like env_create or env_revise. The purpose is understandable but vague.
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, context (e.g., when windows need organizing), or exclusions. With siblings like env_create, env_revise, and env_terminate, there's no indication of how this tool differs in 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?
No annotations are provided, so the description carries full burden. It only states 'query', implying a read operation, but doesn't disclose behavioral traits like pagination (implied by 'page' and 'size' parameters), filtering capabilities (via 'id' and 'name'), rate limits, authentication needs, or what the output looks like. This is a significant gap for a query tool with multiple parameters.
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 phrase '查询分组列表', which is very concise and front-loaded. However, it's under-specified rather than efficiently informative—it lacks necessary details for a tool with 4 parameters. It earns points for brevity but loses some for inadequate content.
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 complexity (4 parameters, 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain the tool's behavior, parameters, or output, leaving the agent with insufficient information to use it correctly. For a query tool with filtering and pagination, this is inadequate.
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. It doesn't mention any parameters or their semantics. The input schema includes 'page', 'size', 'id', and 'name', but the description provides no context on how these affect the query (e.g., pagination, filtering). This leaves parameters undocumented and adds no value beyond 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 '查询分组列表' (Query group list) states the verb 'query' and resource 'group list', which gives a basic purpose. However, it's vague about what exactly is being queried (e.g., all groups, filtered groups) and doesn't distinguish from sibling tools like 'group_create' or 'env_query'. It's not tautological 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. There are sibling tools like 'env_query' and 'proxy_query' for querying other resources, but the description doesn't mention any context, prerequisites, or exclusions. It's a generic statement with no usage instructions.
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. '清理' (clean) implies a destructive operation, but it doesn't specify what gets destroyed (e.g., temporary files, session data), whether it requires specific permissions, or if there are rate limits. The description lacks behavioral details needed for safe invocation.
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 just four characters in Chinese, making it front-loaded and efficient. There's zero wasted space, though this conciseness comes at the cost of completeness.
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 tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the tool's behavior, parameter usage, or expected outcomes, leaving significant gaps for an AI agent to understand and invoke it correctly.
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 3 parameters (id, cacheList, clearEnvFolder), the description adds no meaning beyond the schema. It doesn't explain what 'id' refers to, what items should be in 'cacheList', or what the 0/1 enum for 'clearEnvFolder' means. The description fails to compensate for the low schema 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 '清理环境缓存' (clean environment cache) states a clear verb ('clean') and resource ('environment cache'), but it's vague about what 'environment cache' specifically refers to in this context. It doesn't distinguish from siblings like env_remove or env_terminate which might also clean or remove environment components.
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 siblings like env_remove, env_terminate, and env_terminate_all that might handle environment cleanup, there's no indication of when cache cleaning is appropriate versus full removal or termination.
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 only states the action 'delete environment' without disclosing behavioral traits. It doesn't mention whether this is destructive, irreversible, requires permissions, has side effects, or what happens to associated resources. For a deletion 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two characters ('删除环境'), which is appropriately sized for its minimal content. It's front-loaded with the core action, though this brevity comes at the cost of completeness.
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 deletion tool with 2 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'environment' means in this context, how deletion differs from termination/purge, what the parameters do, or what to expect upon execution. Given the complexity and lack of structured data, it should provide more 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?
Schema description coverage is 0%, so the description must compensate but provides no parameter information. It doesn't explain what 'ids' represents (environment identifiers) or what 'clearEnvFolder' does (likely a flag to clear associated folders). With 2 undocumented parameters, the description adds no value beyond 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 '删除环境' (delete environment) states a clear verb+resource action, but it's vague about what 'environment' refers to and doesn't distinguish from siblings like env_terminate, env_purge_cache, or group_remove. It provides basic purpose but lacks specificity about scope or 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?
No guidance is provided on when to use this tool versus alternatives like env_terminate, env_purge_cache, or group_remove. The description doesn't mention prerequisites, exclusions, or appropriate contexts, leaving the agent with no usage direction beyond the basic action.
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. '批量调整环境分组' implies a batch mutation operation but doesn't disclose behavioral traits: it doesn't specify whether this requires admin permissions, whether it's idempotent, what happens on partial failures, or what the expected output looks like. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single four-character phrase—with zero wasted words. It's front-loaded with the core action. While it may be under-specified, it earns full marks for conciseness as every character serves a 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?
Given the complexity (a batch mutation tool affecting environment-group relationships), lack of annotations, 0% schema description coverage, and no output schema, the description is incomplete. It doesn't explain the operation's scope, side effects, error handling, or return values. For a tool that likely modifies system state, this is inadequate.
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. It mentions '批量' (batch) which hints at the 'ids' array parameter, and '环境分组' (environment grouping) which relates to 'groupId', but doesn't explain what 'ids' represents (e.g., environment IDs), what format they should be in, or what 'groupId' means. The description adds minimal semantic value beyond what's inferable from parameter names.
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 '批量调整环境分组' (Batch adjust environment grouping) states a general purpose (batch adjustment of environment groups) but lacks specificity about what 'adjust' means. It doesn't clearly distinguish from siblings like env_revise or group_revise, which might also modify environment/group relationships. The verb '调整' (adjust) is somewhat vague compared to more precise alternatives like 'transfer' or 'reassign'.
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 siblings like env_revise (likely for modifying individual environments) and group_revise (for modifying groups), the description doesn't clarify that this tool is specifically for bulk transfers between groups. There's no mention of prerequisites, constraints, or typical use cases.
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 for behavioral disclosure. '查询代理列表' implies a read-only operation but doesn't confirm safety, permissions required, rate limits, pagination behavior, or what happens with no parameters. For a tool with 8 parameters and no annotation coverage, this leaves significant behavioral gaps about how the query actually works.
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 at just four characters ('查询代理列表'), which is appropriately sized for a simple query tool. It's front-loaded with the core action and resource. There's zero wasted language or 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 complexity (8 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the query's purpose beyond the basic action, provides no parameter guidance, and offers no behavioral context. For a tool with rich filtering capabilities (8 parameters including enums), this minimal description leaves too much undefined about how to effectively use the tool.
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 descriptions. The description '查询代理列表' adds no information about any of the 8 parameters (page, size, id, provider, type, status, address, remark). It doesn't explain what these parameters filter, their formats, or how they interact. The description fails to compensate for the complete lack of schema documentation.
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 '查询代理列表' (query proxy list) states the basic action (query) and resource (proxy list), which is clear but vague. It doesn't specify whether this lists all proxies, searches/filters proxies, or provides paginated results. Compared to siblings like proxy_create, proxy_remove, and proxy_revise, it distinguishes as a query operation but lacks specificity about scope or filtering capabilities.
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 when to use proxy_query versus other query tools like env_query or group_query, or how it relates to sibling proxy operations (create, remove, revise). There's no indication of prerequisites, typical use cases, 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 the full burden of behavioral disclosure. It states it's a retrieval operation ('获取'), implying read-only behavior, but doesn't specify if it requires authentication, has rate limits, returns specific data formats, or handles errors. For a tool with no annotations, this is insufficient to fully inform the agent about its 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 phrase ('获取单个环境 Cookie'), which is front-loaded and wastes no words. It efficiently conveys the core purpose without unnecessary elaboration, making it easy for an agent 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?
Given the tool's complexity (2 undocumented parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what an 'environment cookie' is, how the parameters work, or what the return value might be. For a retrieval tool with such gaps in structured data, more context is needed to be fully helpful.
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?
The input schema has 2 parameters (id and number) with 0% description coverage, meaning they are undocumented in the schema. The description adds no information about what these parameters mean, their expected formats, or how they relate to retrieving a cookie. It fails to compensate for the low schema coverage, leaving parameters ambiguous.
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 'get' or 'retrieve') and the resource ('单个环境 Cookie' meaning 'single environment cookie'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'env_query' or 'env_profile', which might also retrieve environment-related data, so it doesn't reach the highest 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 any prerequisites, context, or exclusions, such as whether it's for active environments only or how it differs from other query tools in the list. This leaves the agent with minimal 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 a read operation ('获取' - get), implying it's likely safe and non-destructive, but doesn't disclose behavioral traits like authentication needs, rate limits, error conditions, or what happens if the environment doesn't exist. For a 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?
Extremely concise with a single phrase ('获取单个环境详情'), front-loaded and zero waste. Every word earns its place by stating the core purpose without fluff.
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 2 parameters with 0% schema coverage, no annotations, no output schema, and multiple sibling tools, the description is incomplete. It doesn't explain return values, error handling, or how to identify the environment (via id or number). For a tool in a complex environment management system, this leaves significant 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 description must compensate. It mentions no parameters at all, leaving both 'id' and 'number' undocumented. The description doesn't explain what these parameters mean, their relationship (e.g., use one or the other?), or required formats. Baseline would be 1, but it gets a 2 because the tool name 'env_profile' hints at environment identification.
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 '获取单个环境详情' (Get single environment details) clearly states the verb ('获取' - get) and resource ('环境详情' - environment details). It distinguishes from siblings like env_query (likely queries multiple) and env_create (creates new). However, it doesn't specify what 'details' include, keeping it slightly generic.
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 like env_query or env_runtime_state. The description implies it's for retrieving details of a specific environment, but doesn't mention prerequisites (e.g., needing an environment ID) or exclusions (e.g., not for creating or modifying).
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 queries opened environments, implying a read-only operation, but doesn't specify if it requires authentication, returns paginated results, has rate limits, or what the output format might be. For a tool with zero annotation coverage, this is a significant gap in transparency about how it behaves beyond the basic purpose.
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, clear sentence: '查询当前已打开环境列表' (query current opened environment list). It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a simple query tool. Every part of the sentence earns its place by specifying what is being queried.
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 (a query operation with no parameters) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'opened environment' means in this context, what the return values might include (e.g., list format, fields), or any behavioral constraints. For a tool with no structured data to rely on, the description should provide more context to be fully helpful to an agent.
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% (since there are no parameters to describe). With no parameters, the description doesn't need to add semantic details beyond what the schema provides. The baseline for 0 parameters is 4, as there's nothing to compensate for, and the description adequately conveys the tool's purpose without parameter confusion.
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 '查询当前已打开环境列表' (query current opened environment list), which specifies the verb (query) and resource (opened environment list). It distinguishes from siblings like env_create (create) and env_terminate (terminate) by focusing on listing rather than modifying. However, it doesn't explicitly differentiate from env_query (which might query environments more broadly) or env_runtime_state (which might provide runtime details), 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 when to choose env_opened over env_query (which might query all environments, not just opened ones) or env_runtime_state (which might include state details). There's no context on prerequisites, exclusions, or typical use cases, leaving the agent to infer usage from the name and description 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. It implies a destructive operation ('关闭' means close/terminate) but doesn't disclose critical behavioral traits: whether this is reversible, if it requires specific permissions, what happens to running processes, or error conditions. For a zero-parameter mutation tool, this is a significant gap in safety and operational context.
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, direct sentence ('关闭全部已打开环境') with zero waste. It's front-loaded with the core action and appropriately sized for a simple, parameterless tool—every word earns its place.
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 (a destructive, batch operation with no parameters) and lack of annotations or output schema, the description is incomplete. It doesn't explain what 'closed' means (e.g., terminated, suspended, archived), potential side effects, or return values. For a mutation tool affecting multiple resources, more context is needed to ensure safe and correct usage.
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 zero parameters, and schema description coverage is 100% (since there are no parameters to describe). The description doesn't need to add parameter semantics, so a baseline score of 4 is appropriate—it efficiently states the action without redundant parameter details.
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 ('关闭全部已打开环境' translates to 'close all opened environments') with a specific verb and resource. It distinguishes from sibling tools like env_terminate (singular) by specifying 'all' environments. However, it doesn't explicitly contrast with env_purge_cache or env_remove, which might have overlapping cleanup functions.
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 env_terminate (for a single environment) or env_purge_cache (for cache cleanup). It lacks context about prerequisites, such as whether environments must be in a specific state, or warnings about irreversible effects.
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 only states what the tool does (check availability) without describing how it performs the check (e.g., ping, HTTP request, timeout), what 'available' means (e.g., responding within X seconds), or the response format (e.g., boolean, status code, error details). For a diagnostic 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, clear sentence: '检查火云本地服务是否可用'. It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a simple tool. Every part of the sentence earns its place by specifying the action and target.
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 simplicity (0 parameters, no output schema), the description is minimal but incomplete. It lacks behavioral details (e.g., how the check is performed, response format) and usage guidelines, which are crucial for an agent to invoke it correctly. Without annotations or output schema, the description should provide more context about what 'available' entails and what to expect in return.
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% (though trivial since there are no parameters). The description doesn't need to explain parameters, so it meets the baseline expectation. No additional parameter information is required or provided.
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: '检查火云本地服务是否可用' (Check if the Huoyun local service is available). It specifies the verb ('检查' - check) and resource ('火云本地服务' - Huoyun local service), making the purpose understandable. However, it doesn't differentiate from siblings like 'env_runtime_state' or 'env_query' that might also provide service status information, preventing 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, timing (e.g., after deployment or during troubleshooting), or compare it to siblings like 'env_runtime_state' that might offer similar functionality. This lack of context leaves the agent guessing about appropriate usage scenarios.
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:

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

Score Badge

Copy to your README.md:

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

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