qinglong-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action. Although run_crons, run_script, and run_command all involve execution, their descriptions clearly differentiate between cron tasks, script files, and arbitrary shell commands. Similarly, the various log tools are specific to their source, avoiding confusion.
Naming Consistency4/5
Tool names follow a verb_noun pattern with clear resource identification. Minor inconsistencies exist, such as mixing 'create' and 'save' for creating/overwriting files, and inconsistent pluralization (e.g., delete_crons vs delete_script), but these do not undermine predictability.
Tool Count3/5
At 42 tools, the set is large, but it reflects the multi-faceted nature of Qinglong (crons, envs, scripts, subscriptions, configs, dependencies, system). While it exceeds the ideal range, most tools earn their place, though some consolidation could reduce bloat.
Completeness4/5
The surface provides comprehensive coverage for most resources with full CRUD and lifecycle operations. However, subscriptions lack update and delete operations, and there is no single-get for cron tasks, though list_crons provides the data. Minor gaps exist but agents can work around them.
Average 3.6/5 across 42 of 42 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing side effects. It does not state whether running subscriptions is a mutating operation, what consequences it has, or any required permissions, which is a significant gap for an action-oriented tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is efficient and front-loaded. However, the phrasing is ambiguous due to 'Pull/run', which reduces its clarity, though it remains appropriately concise.
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 there is no output schema or annotations, the description should explain behavior and return values. It does not, leaving the tool's actual effect unclear and making the description incomplete for an agent to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'ids' parameter described as 'Array of IDs'. The description merely repeats 'by ids' without adding deeper semantics, such as what the IDs represent or any constraints on their values.
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 identifies the resource (repository subscriptions) and the input (ids), but uses the ambiguous phrase 'Pull/run' which conflates two actions. It does not clearly distinguish this tool from siblings like list_subscriptions or stop_subscriptions.
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?
There is no guidance on when to use this tool versus alternatives. The description lacks any mention of prerequisites, context, or exclusions, leaving the AI agent without information needed to choose it over similar subscription 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action 'Enable' without mentioning side effects, idempotency, error behavior for non-existent IDs, partial failures, or required permissions. For a mutation tool, this is a significant gap.
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, front-loaded sentence with zero wasted words. It is concise and directly to the point, achieving maximum efficiency for the information it conveys.
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 batch operation that enables multiple environment variables, the description omits important context such as return behavior, error handling for invalid IDs, and whether partial updates are possible. With no output schema and no annotations, the agent is left without critical runtime expectations. The tool's simplicity partially mitigates this, but the gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the parameter 'ids' as 'Array of IDs' with 100% coverage. The description adds minimal context by clarifying these are environment variable IDs, but does not elaborate on format, constraints, or how IDs map to the action. Baseline of 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Enable environment variables by ids' clearly states a verb (Enable), a resource (environment variables), and a method (by ids). It distinguishes from sibling tools like disable_envs (opposite action) and list_envs/create_env (different operations), though the scope could be slightly more explicit about targeting disabled variables.
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 does not state that it should be used for re-enabling previously disabled environment variables, nor does it mention any prerequisites or contrast with enable_crons/enable_subscriptions. The naming convention implies usage but the description carries no explicit guidance.
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, the description carries the full burden of behavioral disclosure. It only says 'Enable' without specifying effects on already-enabled subscriptions, error conditions, or whether it is reversible. The description lacks any detail beyond the action itself.
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, front-loaded sentence with no wasted words. However, it is somewhat under-specified, so while concise, it does not fully earn its place by adding value.
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 one parameter and no output schema, the description should at least explain what happens after enabling subscriptions or what the return value is. It is too brief for a mutation tool, leaving the agent without critical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% as the 'ids' property includes a description ('Array of IDs'). The tool description does not add additional meaning beyond the schema, so the baseline score of 3 is appropriate.
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 'Enable' and the resource 'subscriptions', distinguishing it from sibling tools like disable_subscriptions. However, 'by ids' is redundant with the schema and does not add scope, so it lacks the specificity of a 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?
No guidance is provided on when to use this tool versus alternatives like disable_subscriptions, run_subscriptions, or stop_subscriptions. The usage context is only implicit in the tool's name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states only that it reads content, but does not disclose return format, whether path is required for subdirectories, potential errors, or any other behavioral traits beyond the obvious read operation.
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 sentence with no wasted words, making it extremely concise and front-loaded. However, it is arguably too sparse given the lack of annotations and context, preventing a perfect score.
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 two parameters, no output schema, and no annotations, the description is too minimal. It does not mention return values (e.g., raw content, JSON wrapper), error behavior, or how the optional path affects lookup, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for both parameters ('File name (required)' and 'Sub-directory path, optional'), covering 100% of parameters. The description adds no parameter-specific information, so the baseline score of 3 is appropriate.
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 'Read a script file's content' uses a specific verb and resource, clearly indicating the tool's function. It is unambiguous, though it does not explicitly distinguish from sibling tools like list_scripts or run_script, which is why it does not receive a 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 offers no guidance on when to use this tool versus alternatives. There is no mention of preferred contexts, prerequisites, or exclusions, leaving the agent to infer usage from the tool name and sibling names.
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, the description carries the full burden of behavioral disclosure. It only states the action without addressing side effects, permissions, idempotency, error handling, or what happens if labels do not exist on the specified tasks.
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, front-loaded sentence with no unnecessary words. While it could be expanded with usage and behavioral details, the brevity itself is not a flaw.
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?
As a mutation tool with no annotations and no output schema, the description omits important context such as return values, scope of removal (e.g., multiple tasks), edge cases, and potential side effects. This leaves the agent without enough information to use the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters ('Array of IDs' and 'Labels to remove') with 100% coverage, so the description adds no additional parameter context. The baseline of 3 is appropriate since the description does not contradict or enhance the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and clear resource ('labels from cron tasks'), making the tool's purpose immediately apparent. It distinguishes itself from sibling tools like add_cron_labels (opposite action) and update_cron (broader updates).
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 add_cron_labels or update_cron. It lacks any mention of prerequisites, context, or situations where this tool is preferred.
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 for behavioral disclosure. It only states 'Add labels to cron tasks' without detailing whether labels are appended or replaced, how duplicates are handled, or what happens on invalid IDs. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that gets straight to the point with no wasted words. It is appropriately sized for the tool's simplicity.
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 that there are no annotations and no output schema, the description should explain return values and side effects. It does not mention what happens after adding labels, whether the operation is idempotent, or whether it errors on nonexistent IDs. This leaves the description incomplete for a mutation tool, though the parameter schema is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for both parameters (ids and labels), so the baseline is 3. The description adds no additional meaning beyond the schema, such as clarifying that IDs refer to cron task identifiers or that labels are string arrays. No extra semantic value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add labels to cron tasks' uses a specific verb (add) and resource (cron tasks), clearly stating the action. It distinguishes from the sibling tool remove_cron_labels by direction, making the purpose unambiguous.
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 update_cron or remove_cron_labels. The description does not mention usage context, prerequisites, 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 present, so the description carries the full burden. It merely states 'Disable subscriptions by ids' without explaining what disabling entails, whether it is reversible, or how it affects running subscriptions. This is insufficient for a mutation-like tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded and easy to parse, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations or output schema, the description is too sparse. It doesn't differentiate disable from stop, explain side effects, or indicate when the operation is appropriate. The tool is simple but the description leaves important contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the 'ids' parameter with a description ('Array of IDs') and coverage is 100%. The description adds no new semantic detail beyond saying 'by ids', so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Disable') and the resource ('subscriptions'), and specifies the input via 'by ids'. This distinguishes it from sibling tools like enable_subscriptions and stop_subscriptions by using a different verb.
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 stop_subscriptions or enable_subscriptions. There is no mention of prerequisites, use cases, or exclusions, leaving the agent to guess the appropriate 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'disable' without explaining what that entails—whether it is reversible, if it affects running processes, or if any confirmation or side effects occur. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that wastes no words. It is front-loaded and immediately communicates 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?
For a simple single-parameter tool, the description is minimally adequate but incomplete. It does not explain what 'disable' means in terms of system behavior or whether it can be undone, which is necessary context for an agent to confidently invoke the 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?
The schema has 100% coverage for the single 'ids' parameter with its own description ('Array of IDs'). The tool description adds 'by ids', which merely confirms the parameter's role but does not provide additional context like ID format, constraints, or behavior when invalid IDs are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Disable environment variables by ids' clearly states the verb (disable), resource (environment variables), and method (by ids). It effectively distinguishes this tool from siblings like enable_envs, delete_envs, and list_envs.
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 does not mention prerequisites, context for disabling, or indicate that enable_envs could reverse the operation.
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, the description carries the full burden, but it only states the action without disclosing any behavioral details such as read-only nature beyond the verb, error conditions, or what exactly constitutes the 'latest log'. No side effects, permissions, or response characteristics are described.
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?
A single, front-loaded sentence that is concise and free of irrelevant content. 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?
The tool is simple with one parameter and no output schema, so the description is minimally adequate. However, it omits what the returned log contains, whether it returns a single entry or multiple, and any potential failure modes, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the only parameter ('Subscription id (required)'), so the description's mention of 'by id' adds no new meaning. With 100% schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('log of a subscription') with a clear identifier ('by id'). It clearly distinguishes from siblings like get_cron_log or get_log by specifying the subscription 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 given on when to use this tool versus alternatives like list_logs or get_log. There is no mention of prerequisites, edge cases, or why one would choose this over sibling 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?
With no annotations, the description must carry full behavioral disclosure. It only states the action and location, but does not mention behavior like recursive listing, output format, pagination, or any limitations. 'List' implies read-only, but other details are absent.
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 that immediately conveys the purpose. There is no redundant information or unnecessary elaboration.
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?
While the tool is simple, the description lacks details on return values or how the optional path affects results. With no output schema to fill this gap, the description feels minimally complete but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the 'path' parameter as an optional sub-directory path. The description adds no additional semantic detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists script files in Qinglong's script directory, using a specific verb 'list' and a distinct resource. It differentiates from sibling tools like list_crons and list_envs by specifying 'script files'.
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 get_script or run_script. There is no mention of exclusions, prerequisites, 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?
With no annotations, the description carries the full burden. It only states the action and context ('in Qinglong') but does not disclose read-only behavior, return format, possible side effects, or prerequisites. This is a significant gap for a tool operating on external state.
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?
A single, clear sentence with no wasted words. It is concise and front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, this is minimally viable. However, it lacks details like pagination, result format, or any behavior specifics, which could help an agent ensure correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the only parameter (searchValue as 'Keyword filter'), giving 100% coverage. The description adds nothing beyond this, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists repository subscriptions in Qinglong, with a specific verb and resource. It implicitly distinguishes from sibling tools like create_subscription or enable_subscriptions, which perform mutations.
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 when-to-use or alternative guidance is provided. The agent gets no help choosing between this and related subscription tools, aside from the obvious distinction inferred from the name.
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, the description carries full responsibility for disclosing behavior. It only states 'Stop running cron tasks by ids' without revealing side effects, reversibility, permission requirements, or impact on future schedules. This is nearly a restatement of the tool name.
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, front-loaded with the action and target. Every word contributes value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description provides the basic operation. However, it lacks clarification on how stopping differs from disabling or deleting, and does not mention return values or side effects. It is minimally viable but leaves meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter 'ids' described as 'Array of IDs'. The description adds minimal meaning by mentioning 'by ids', but the schema already provides the necessary semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Stop') and resource ('cron tasks') with a clear scoping mechanism ('by ids'). It clearly distinguishes from siblings like delete_crons or disable_crons by indicating it targets running tasks.
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 disable_crons, delete_crons, or run_crons. The description simply states the action without specifying exclusions, prerequisites, or timing considerations.
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 simply states 'Stop running subscriptions' without disclosing side effects (e.g., whether it terminates active runs, is reversible, or affects future schedules), permissions, or prerequisites. This ambiguity is significant for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, direct sentence with no filler. It states the action and the input clearly, making it highly concise and front-loaded.
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?
As a mutation tool with no annotations or output schema, this description is under-specified. It lacks operational details such as reversibility, impact on current executions, or how it differs from disable/enable. Given sibling tools exist, this is an incomplete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter is already documented. The description adds nothing beyond 'by ids', which the schema already conveys as 'Array of IDs'. Baseline 3 applies because schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Stop' with a clear resource 'running subscriptions' and scope 'by ids', distinguishing it from sibling tools like enable/disable/run. The purpose is immediately obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: use when you need to stop running subscriptions. However, there is no explicit guidance on when to prefer this over disable_subscriptions or run_subscriptions, nor any exclusions or alternatives mentioned.
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, the description carries the burden of disclosing side effects. It only states creation and defaults; it does not mention what happens after creation, whether it overwrites, any prerequisites, or response type. The defaults add minor behavioral context but the mutation is largely opaque.
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?
Two sentences, front-loaded with the purpose. The required parameter and defaults are stated concisely with no irrelevant content.
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?
The schema already documents all 11 parameters, so the description does not need to repeat them. However, there is no output schema and no annotations, so the description should explain the behavior of subscription creation, which it does not. The high-level context is thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds a default for 'type' (public-repo) and clarifies the URL format, but the required flag and schedule_type default are already in the schema. The added value is incremental.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a repository subscription' with a specific verb and resource. It adds useful defaults and highlights the required parameter, distinguishing it from other create_* tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a required parameter and defaults, implying when to use the tool, but does not explicitly compare to alternatives or state exclusions. No guidance on when to select this versus run_subscriptions, enable_subscriptions, or when to use interval vs cron.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It does disclose the critical trait of irreversibility with a warning emoji, which is valuable. However, it does not mention permissions, side effects on associated data (e.g., logs), or partial deletion behavior, so it provides only minimal behavioral context beyond the action itself.
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 two short sentences that immediately convey the action and a critical warning. Every word is meaningful, and it is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter, the description covers the core action and a warning. However, it lacks details about return values, error handling (e.g., partial deletion), or any usage constraints, which would be helpful for an agent to invoke it correctly in all scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the parameter (ids as an array of numbers with 'Array of IDs'). The description's phrase 'by ids' adds no additional semantic detail about the IDs' meaning, format, or constraints. Given 100% schema coverage, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function with a specific verb ('Delete') and resource ('cron tasks'), plus the method ('by ids'). It unambiguously distinguishes from sibling tools like list_crons, create_cron, and update_cron, and is not a tautology.
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, any prerequisites, or exclusions. The description only states what it does, leaving the agent to infer usage entirely from the tool's name and the destructive 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?
There are no annotations, so the description carries the full burden. While 'Read' implies a non-mutating operation, the description does not disclose what happens if the path is invalid, whether the content is returned raw or parsed, or any other behavioral details. It adds no context beyond the verb itself.
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 sentence with no unnecessary words. It is front-loaded with the main verb and object, and 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?
The tool is simple with one parameter, but there is no output schema and no annotations. The description does not mention the return format or error behavior, leaving some gaps for an agent to invoke the tool correctly in edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for the 'path' parameter is already detailed ('Config file path, e.g. config/config.sh (required)'), providing 100% coverage. The tool description's 'by path' adds little extra meaning beyond what the schema already conveys, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and resource ('config file's content') with a clear scope ('by path'). It distinguishes from siblings like list_configs (which lists configs) and save_config (which writes), making the tool's function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need the content of a specific config file, but it does not explicitly state when to choose this over alternatives like list_configs or provide any exclusions. No 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. 'Read' indicates a read-only operation, but it lacks details about error handling, authentication, or return format. The transparency is acceptable for a simple read tool but not rich.
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 that front-loads the action and resource. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and comprehensive parameter schema, the description is mostly adequate. However, with several sibling log-related tools, it lacks context to differentiate when this generic log reader should be used instead of get_cron_log or get_subscription_log. This is a clear gap in contextual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the two parameters (file and path). The description adds 'path/file' which essentially restates the schema fields, providing no extra semantic value beyond what the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Read') and resource ('log file's content'). It also specifies the method ('by path/file'), which distinguishes it from list_logs and the specialized cron/subscription log 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 like get_cron_log or get_subscription_log. The description implies usage by stating what it does, but it does not explicitly differentiate it from sibling 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 responsibility. It only says 'Stop a running command' but does not disclose that this is a destructive/irreversible action, any side effects on child processes, or whether the stop is graceful or forceful. The source of the pid is left to the 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, concise sentence that immediately conveys the tool's purpose. No unnecessary words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description provides the essential action and identifiers, but misses important context: whether one identifier is mandatory, how to obtain the pid from run_command, and what the outcome/return value is. The absence of annotations increases the need for more contextual detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's 'by pid (or command text)' adds little beyond restating the parameter names. It fails to clarify that 'or' implies at least one is required, and whether both can be supplied together.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Stop') and resource ('a running command... by pid or command text'), distinguishing it from sibling tools like stop_crons or stop_subscriptions. The target is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to terminate running commands, but provides no explicit guidance on when to choose it over alternatives, how to obtain the pid, or that either pid or command text is required. No exclusions or alternatives are mentioned.
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 disclosing behavioral traits. It only says 'Run a script file directly,' which gives zero detail about side effects, permissions, output, failure modes, or safety considerations. Executing a script is potentially destructive or side-effectful, and the description does not warn or explain anything 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It front-loads the action and adds a critical distinction (not via cron) in a compact form. Every word earns its place, and it is appropriately sized for the clarity it provides.
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?
This is a high-complexity tool (arbitrary code execution) with no annotations and no output schema. The description is extremely minimal, lacking any mention of side effects, prerequisites, return behavior, or relationship to script-management tools. For such a powerful and risky operation, the description is incomplete and leaves the agent with insufficient behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so each parameter already has a descriptive meaning (path, content, filename). The description adds only 'ad-hoc execution' context but does not clarify parameter relationships or usage. Baseline 3 is appropriate since the schema does the heavy lifting and the description provides no additional parameter-level value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Run') and resource ('a script file') with a specific scope ('directly', 'ad-hoc execution'). The phrase 'not via cron' explicitly distinguishes it from scheduling tools, making the purpose unambiguous. This exceeds the baseline of just naming the tool and differentiates it from siblings like create_cron or list_scripts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this is for ad-hoc, immediate execution rather than scheduled execution. The exclusion of cron is explicitly stated, which helps guide selection against cron-related tools. However, it does not name alternatives or provide explicit 'use this when' versus 'use that when' guidance, so it falls short of a full 5.
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. It only restates the core action without mentioning error handling, whether updates are partial or full, idempotency, or return values. For a mutation tool, this is a significant gap.
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 sentence, immediately front-loaded with the verb and resource, and contains no extraneous information. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter mutation tool with no output schema, the description is adequate but minimal. It omits details about partial update behavior and return values, which could be important for the agent. The schema covers parameters, but the description does not provide additional operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all four parameters with clear meanings, so the description's mention of 'name/value/remarks' adds no additional insight. The baseline of 3 applies because schema coverage is 100% and the description does not conflict or enhance it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') with a clear resource ('environment variable') and scope ('by id'). It also lists the fields (name/value/remarks), which distinguishes it from sibling tools like create_env, delete_envs, and list_envs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear that this tool modifies existing environment variables, and the 'by id' phrasing indicates it is for specific instances. However, it does not explicitly state when not to use it (e.g., for creating new variables) or name alternatives, though the verb and sibling tools imply the use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It explains that the tool accepts a single dependency or an array, and defines the type numbers, but it does not disclose side effects, permissions, or return values. This is a basic level of transparency for an install operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no waste. It front-loads the primary purpose, then provides the type mapping and input format, making it highly concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters and full schema coverage, the description covers the input modes and type semantics effectively. It lacks explicit mention of return values or post-install behavior, but for a simple create/install tool, the essentials are present. No output schema exists, yet the description is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the two modes (single vs. array), but the phrase 'envs / items' is slightly ambiguous and does not robustly clarify the item structure beyond the schema. Thus, it adds some but not great semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Install dependencies' with a specific verb and resource, and provides the type mapping (1=node, 2=python, 3=linux). This distinguishes it from siblings like list_dependencies and delete_dependencies, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning single vs. array inputs, but it does not explicitly state when to use this tool instead of alternatives, nor does it mention any exclusions or prerequisites. It relies on the verb 'install' to convey the intended context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly warns '⚠️ Irreversible,' which is a critical behavioral trait for a destructive operation. However, since no annotations are provided, the description carries the full burden and does not mention permissions, atomicity, error handling, or other side effects, leaving the disclosure somewhat minimal.
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 sentence front-loaded with the verb and resource, followed by a concise warning label. Every word contributes to understanding the tool's function and critical caveat, with zero wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter, the description covers the essential aspects: what is deleted, how it is identified (by ids), and that the action is irreversible. While it omits details on return values or edge cases, the low complexity and absence of an output schema make this reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the 'ids' parameter with 100% coverage, and the description adds meaning by clarifying that these are dependency IDs and that the operation is performed 'by ids.' This reinforces the parameter's purpose beyond the generic 'Array of IDs' schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Delete installed dependencies by ids,' clearly specifying the action (delete), the resource (dependencies), and the selection mechanism (by ids). This distinguishes it from sibling tools like delete_crons or delete_envs by identifying the exact target resource.
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, nor any prerequisites, exclusions, or recommended scenarios. It merely states the action without contextual cues, leaving the agent to 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool pauses scheduling (a non-destructive mutation), but does not mention reversibility, effect on currently running tasks, or error behavior for invalid IDs. It adds some value but lacks rich behavioral 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?
Single, front-loaded sentence with no wasted words. It clearly states the action, target, and qualifier.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema and no annotations, the description adequately covers purpose and key behavior. It could mention reversibility or interactions with sibling tools, but given the tool's simplicity, this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with a description for the 'ids' parameter, so baseline is 3. The description reinforces that IDs target cron tasks and adds the context of disabling/pausing, but does not provide additional format or constraint details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Disable') with a clear resource ('cron tasks') and method ('by ids'), and clarifies the effect as 'pause scheduling,' which distinguishes it from sibling tools like delete_crons or stop_crons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'pause scheduling' implies this is for temporarily disabling rather than deleting or stopping, but the description does not explicitly state when to use this tool versus alternatives like delete_crons or enable_crons, nor does it name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action ('enable') without mentioning side effects, idempotency, permission requirements, or response format. This is a state-changing operation, and the description provides no additional transparency beyond the name.
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, front-loaded sentence with no redundant wording. It efficiently conveys the action, the resource, and the mechanism without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter enable operation, the description is largely complete. It clarifies the intent (resume scheduling) and the target. Minor gaps like error handling or behavior on already-enabled tasks exist, but these are not critical given the low complexity and lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with one parameter (ids), and the description 'by ids' aligns with it. The description adds minimal nuance by specifying the resource but does not elaborate on the meaning of the IDs or any constraints, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'enable' and the resource 'cron tasks', with the scope limited to a set of IDs. The parenthetical 'resume scheduling' distinguishes this from sibling tools like run_crons or disable_crons, making the purpose immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'resume scheduling' provides clear context for when to use this tool: to re-enable cron tasks that were previously disabled or stopped. However, it does not explicitly state when not to use it or mention alternatives, though the sibling list makes the distinction inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description carries the burden of disclosing behavior. 'Get' indicates a read operation, but the description does not explain what happens if the id doesn't exist, whether the value is returned, or if any permissions are needed. For a simple getter, this is adequate but not rich.
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 one short sentence that is front-loaded and contains no fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is mostly adequate. It clearly states the purpose. However, it could mention the return format or read-only nature, but these are largely implied by the name and description. This is slightly above minimum viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (id) with 100% description coverage ('Env var id (required)'). The description's phrase 'by id' adds minimal extra meaning beyond the schema, so it does not significantly enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a single environment variable by id' uses a specific verb (get) and resource (environment variable) with a clear scope (single, by id). This distinguishes it from siblings like list_envs (list all) and update_env/delete_envs (mutations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need a single env var by id) but does not explicitly mention alternatives or when not to use it. For example, it doesn't say 'use list_envs to fetch all variables' or 'use get_config for config values.' The context is clear but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb 'List' implies read-only operation, but with no annotations, the description carries the full burden. It does not mention return format, pagination, error conditions, or whether this operates on local files or remote resources. The examples provide some context, but it remains a minimal description.
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, front-loaded sentence with no redundant words. It includes useful examples without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero-parameter schema and simple purpose, the description is largely sufficient. It does not explain the exact return value (likely a list of file names), but this is strongly implied by the verb 'List'. Overall, it is adequate for a tool of this complexity.
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?
There are zero parameters, so the baseline is 4. No parameter documentation is needed, and the description does not introduce any ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the specific resource ('Qinglong config files') with concrete examples (config.sh, auth.json). This distinguishes it from sibling tools like get_config (single file retrieval) and save_config (modification).
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 does not mention any exclusions or relationships to get_config, list_scripts, or other listing tools, leaving the agent without explicit contextual cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'List' implies a read-only operation, but the description does not explicitly disclose safety characteristics, permissions, or side effects. It is minimally adequate for a simple listing tool but lacks detail.
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 sentence that is front-loaded with the action and resource. It contains no filler and every word contributes to meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with no parameters and no output schema. The description adequately conveys the purpose and scope (node/python/linux packages). It is slightly ambiguous whether dependencies are system-wide or project-specific, but that is a minor gap.
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 the schema coverage is 100% (empty properties). Per the rubric, the baseline for 0 params is 4, and the description does not need to elaborate on parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'installed dependencies' and clarifies the categories (node/python/linux packages). This clearly distinguishes it from sibling list tools like list_crons and list_envs.
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 or any exclusions. The description only states what it does, leaving usage context to inference from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose that the tool lists environment variables, including sensitive ones like cookies and credentials, and supports optional filtering via searchValue. However, it does not explicitly state that this is a read-only operation or describe what is returned, relying on the verb 'list' to imply non-destructive 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 two short sentences with no filler. It front-loads the verb and resource, and adds the optional filter in a second concise sentence, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description adequately covers purpose, resource, and filtering capability. It could optionally mention the return format or explicitly state read-only behavior, but for its complexity, the description is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the schema already explaining that searchValue filters by name/remarks. The tool description only mentions 'Optionally filter with searchValue' without adding further meaning, so it does not significantly enhance the parameter documentation provided by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists environment variables in Qinglong, using the specific verb 'list' and identifying the resource. It distinguishes from sibling tools like get_env (which retrieves a single environment variable) and list_crons (which lists cron jobs) by the resource type and context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need to view environment variables, but it does not explicitly state when to use this tool versus alternatives like get_env. There is no mention of exclusions or when to prefer another tool, leaving usage guidance implied rather than explicit.
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 discloses that only 'accessible' log files are listed, which hints at permission filtering, but it does not describe the output format, whether pagination is used, or any other behavioral detail. For a listing operation, this is sparse.
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 that directly conveys the tool's purpose. Every word contributes, and there is no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description is reasonably complete for its purpose. It tells the agent what the tool does and what it operates on. However, it could be enhanced by mentioning the intended follow-up action (e.g., using get_log) or clarifying what 'accessible' means in practice, but this is optional for a straightforward list operation.
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 accepts zero parameters, so the description does not need to explain parameter meanings. The baseline for 0 parameters is 4, and the description appropriately avoids adding unnecessary parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('accessible log files') with a location context ('on the Qinglong server'). It distinguishes itself from sibling tools like get_log, which retrieves a specific log, by focusing on listing the available log files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for enumerating accessible log files, but does not explicitly state when to use it versus alternatives like get_log. There is no mention of prerequisites or exclusions, so the usage guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It does reveal key traits: 'create/overwrite' indicates potential overwriting of existing files, and the warning 'Can change panel behavior' highlights a significant side effect. However, it omits other details like permission requirements or reversibility, making it minimally transparent.
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: one sentence plus a warning emoji. Every word adds value—'Save (create/overwrite)' clarifies the operation, and 'Can change panel behavior' is a high-impact caution. There is zero filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 parameters, no output schema), and the description covers the core action and a critical side effect. It could arguably include what happens after saving (e.g., reload behavior) or specify file paths, but the warning and overwrite note provide sufficient context for a basic save operation. Sibling tools like list_configs and get_config imply that saving is one part of a larger workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for both parameters (name and content), so the schema already provides adequate descriptions. The tool description adds no additional parameter-level semantics beyond what the schema states, so the score matches the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Save (create/overwrite)') and resource ('config file'). It distinguishes itself from siblings like save_script and list/get_config by specifying config file creation/overwriting. The 'create/overwrite' also clarifies the exact behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a config file needs to be saved, but provides no explicit 'when to use' guidance or alternatives. The warning 'Can change panel behavior' signals caution but does not address when not to use the tool or compare to similar tools. Thus, usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the potentially destructive overwrite behavior ('or overwrite'), but lacks details on permissions, directory creation, or scope of the file path. The mention of 'overwrite' is a useful warning, but more context would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the action verb. Every word is relevant, with no filler or repeated schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with three well-documented parameters and no output schema. The description covers the primary action and the overwrite behavior, which is sufficient for most use cases. It could mention edge cases like path handling, but the schema fill that gap, making this reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters, so the baseline is 3. The description adds no additional meaning beyond the schema; it only restates that content is provided. It does not explain path semantics or format beyond what the schema already describes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create or overwrite') and the resource ('a script file') with specific content. This distinguishes it from sibling tools like list_scripts, get_script, run_script, and delete_script, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating or updating a script file, but it does not explicitly state when to prefer this over alternatives (e.g., save_config) or when not to use it. There are no exclusions or alternative tool references.
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 responsibility for behavioral disclosure. It only says 'Create a new cron task' and gives parameter requirements, but does not disclose side effects, whether the cron starts immediately, permission requirements, or return behavior. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with a clear verb-first structure. It wastes no words and front-loads the main purpose, while effectively embedding examples.
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 7 parameters and no output schema or annotations, the description is somewhat minimal. It only addresses the two required parameters and gives no guidance on optional parameters, creation behavior, or possible errors. For a moderately complex create operation, this feels incomplete but not severely inadequate.
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 schema already covers all 7 parameters with descriptions, giving a baseline of 3. The description adds value by providing concrete examples for command (`ql task xxx.js`) and schedule (`0 8 * * *`), reinforcing the required format and clarifying that command can be any shell command.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new cron task' with a specific verb and resource, distinguishing it from sibling tools like update_cron and delete_crons. It also specifies the required inputs with examples, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states that command and schedule are required, giving clear conditions for using this tool. It does not mention alternatives or exclusions, but the context is clear enough for a creation tool among siblings like list_crons and update_cron.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It does add a useful naming constraint (must start with letter/underscore, allowed characters) that goes beyond the schema. However, it fails to mention important behaviors like handling duplicate names, permissions, or whether the operation overwrites.
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, front-loaded sentence that states the purpose and a key constraint without any fluff. 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?
The tool is simple and the schema covers all parameters, but there are no annotations and no output schema. The description omits important context such as what happens if the environment variable already exists, or what the return value looks like. This leaves gaps for an agent selecting and invoking the tool, though the low complexity keeps it from being a major issue.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, giving a baseline of 3. The description adds meaning for the name parameter by specifying the required pattern (starting with letter/underscore, only letters/digits/underscores), which is not present in the schema's parameter description. Value and remarks are not elaborated, but the added rule justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('environment variable'), making it immediately obvious what the tool does. It also distinguishes from sibling tools like update_env and delete_envs by specifying the create operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The verb 'Create' implies usage for new environment variables, but there is no explicit guidance on when to use this versus alternatives (e.g., update_env for existing variables). No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. The explicit '⚠️ Irreversible' warning highlights the permanent destructive nature, which is essential for a delete tool. However, it does not disclose behavior for invalid IDs or partial failures, which prevents a perfect score.
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 consists of two short sentences. The first is front-loaded with the action and resource, and the second adds a critical warning. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a low-complexity tool with a single parameter and no output schema. The description covers the main action and the critical irreversible nature. It does not address partial failure behavior or prerequisites, but given the simplicity and the inclusion of the most important safety warning, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the single parameter 'ids' with a description 'Array of IDs', achieving 100% coverage. The description adds context that these are environment variable IDs, but this is already clear from the tool name and resource. No additional parameter semantics beyond the schema are provided, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Delete') on a specific resource ('environment variables') with a qualifier ('by ids'). This distinguishes it from sibling tools like enable_envs, disable_envs, and update_env. The additional warning about irreversibility reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need to permanently delete environment variables and have their IDs. The irreversibility warning provides caution but does not explicitly contrast with alternatives like disable_envs for temporary deactivation. No explicit 'use this when' or 'instead of' guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 clearly warns '⚠️ Irreversible,' which is a critical safety trait beyond the basic 'delete' verb. However, it does not mention permissions, path behavior, or what happens if the file does not exist.
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: one short sentence plus a warning symbol. Every word earns its place, and the most critical information (irreversibility) is highlighted immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with only two parameters (both documented in the schema) and no output schema, the description covers the essential purpose and key risk. It could mention path semantics or failure behavior, but the core information is present and the tool is relatively low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for both parameters (path and filename), with 100% schema description coverage. The tool description itself adds no parameter-specific semantics, so it does not exceed the baseline for a fully documented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Delete a script file' — a specific verb and resource that clearly distinguishes it from sibling tools like delete_crons or delete_envs. The scope is explicit (a single script file), so there is no ambiguity about what operation is being performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit when-to-use or when-not-to-use guidance, nor does it name alternatives. The resource type is obvious, so usage is implied, but there is no mention of constraints like requiring the script to be not running or needing a specific path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It accurately implies a read-only operation ('Get') and identifies the resource, but it does not disclose behaviors such as what happens if no log exists, potential errors, or response format. For a simple getter, this is adequate but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that effectively communicates the tool's function without any fluff. It is front-loaded by starting with the verb 'Get' and includes the key qualifiers 'latest' and 'by id', making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, no output schema), the description is mostly sufficient. It clearly explains what the tool does and how it identifies the target. The main missing piece is a statement about return values or error behavior, but for a simple fetch operation this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% as the single parameter 'id' is described as 'Cron task id (required)'. The tool description adds no new information beyond 'by id', so it relies on the schema. This meets the baseline for high coverage but adds no extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'Get', the resource 'latest execution log of a cron task', and the lookup key 'by id'. This distinguishes it from sibling tools like list_logs (list) and get_subscription_log (different resource), making the tool's unique purpose immediately apparent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool retrieves the latest execution log for a specific cron task identified by id. It does not explicitly name alternatives or exclusions, but the context is strong enough to infer when to use it, especially compared to the related get_log or list_logs tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the partial-update behavior (unchanged fields retain values), which is valuable. However, it does not mention permissions, reversibility, or side effects. The description is adequate for a simple update but not highly transparent.
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?
Two concise sentences that are front-loaded with the core purpose. Every word earns its place, no repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward update tool with full schema coverage and no output schema, the description is adequate. It covers the essential usage (id required, partial update). It misses potential error conditions or permission requirements, but these are not critical for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already documented. The description adds the general guidance about only including fields to change, which is more behavioral than param-specific. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Update an existing cron task by id.' It specifies the verb (update), the resource (cron task), and the key requirement (id). This distinguishes it from create_cron and delete_crons siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage guidance: 'Only include the fields you want to change; id is required.' This implies partial update semantics and sets the prerequisite. It does not explicitly mention alternatives or exclusions, but the sibling tool names make context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the operation returns all tasks with key fields and supports an optional filter, which covers safety and scope. It does not mention edge cases like pagination or exact matching, but these are less critical for a list operation.
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?
Two concise sentences, no filler. Information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description adequately covers the action, return content, and filtering. It could mention behavior for empty results or default sorting, but it's largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents searchValue as 'Keyword to filter tasks', and the description mentions it as optional, adding no new semantics. Since schema coverage is 100%, the baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List cron tasks in Qinglong panel' with a specific verb and resource. It also details the return fields and optional filtering, distinguishing it from mutation tools like create/update/delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a read-only listing operation with optional keyword filtering. It does not explicitly name alternatives or exclusions, but the context makes clear when it applies relative to sibling cron management tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the operation is asynchronous ('async') and directs to get_cron_log for output inspection, which are important behavioral traits. It does not mention side effects, concurrency, or error behavior, but for a simple trigger tool the disclosed information is meaningful.
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 sentence that is front-loaded with the action ('Trigger cron tasks to run immediately') and includes the async caveat in parentheses. Every word earns its place with no redundancy or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the essential aspects: the action, the async behavior, and how to retrieve results. It does not mention potential permissions or error cases, but for a simple one-parameter trigger tool, the provided information is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single required parameter 'ids' described as 'Array of IDs'. The description does not explicitly state that 'ids' refers to cron task IDs, though it is strongly implied by the tool name and description. This is adequate but not additive beyond the schema's minimal definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'trigger' with resource 'cron tasks' and the scoping phrase 'run immediately', which clearly differentiates it from siblings like list_crons, create_cron, update_cron, delete_crons, stop_crons, enable_crons, and disable_crons. It is unambiguous that this tool executes a one-off immediate run of existing cron tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the primary use case ('run immediately') and explicitly points to get_cron_log for inspecting output, which establishes a clear workflow. It does not explicitly name alternatives or exclusions, but the async note and sibling names imply when this tool is appropriate relative to scheduling or monitoring tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the supported channels, the requirement to match 'type' to the configured channel, and the default-channel fallback. However, it does not explain behavior on failure (e.g., invalid channel, unreachable endpoint) or the return format, which are important for a send operation.
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 sentence followed by an inline example. It is front-loaded with the core purpose and adds the critical usage detail without unnecessary fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, a nested object, and no output schema. The description covers purpose, channel options, parameter semantics, and default behavior, which is sufficient for a simple notification sender. It lacks error handling details, but these may be less critical given the straightforward nature of the operation.
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 schema already describes all three parameters (100% coverage), so baseline is 3. The description adds meaningful value by providing a concrete example with serverChan and its key field, and by explaining that omitting notificationInfo uses the system default channel. This goes beyond the schema's bark example and clarifies the expected structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Send a notification through Qinglong's notification system', which clearly states the action (send) and resource (Qinglong notifications). It lists multiple supported channels and is distinguished from all sibling tools, which are cron/env/script management operations. The purpose is unambiguous and precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this is the tool to use when sending notifications, and there are no alternative notification tools in the sibling list. It provides explicit guidance on when to include notificationInfo (matching configured channel) and when to omit it (use system default). No exclusions are needed because no alternatives exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. The description discloses the specific fields returned, which is useful. However, it does not explicitly state that this is a read-only operation with no side effects or mention any prerequisites or potential errors, though the 'get' verb implies safety.
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, front-loaded sentence that conveys the purpose and the key returned fields. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with no parameters and no output schema. The description lists all relevant return fields (version, init state, branch, changelog), making it complete for an agent to understand what to expect. There is no missing critical context.
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 the schema is empty. The description adds no parameter details because none are needed. With 0 params, baseline is 4, and the description does not need to compensate for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'Qinglong system info', listing specific fields (version, init state, branch, changelog). This distinguishes it from sibling tools which focus on crons, envs, scripts, subscriptions, configs, and dependencies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear when to use this tool: to retrieve system-level information. Since no sibling tool provides system info, there are no alternatives to exclude, so the context is clear and no explicit exclusions are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the dangerous nature, the host-shell (unrestricted) environment, and that the command is arbitrary. However, it does not describe the return value (e.g., stdout/stderr) or potential side effects/permissions, which would be useful for such a low-level tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence front-loaded with a danger warning. It includes essential guidance without any fluff, and every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one param, no output schema), but it is dangerous. The description adequately warns and guides usage, though it could mention what the tool returns (e.g., command output) or that it runs synchronously. Overall, it is complete enough for an agent to invoke safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the command parameter with 100% coverage. The description adds the word 'arbitrary' and clarifies the shell context, but these are largely redundant with the schema. The baseline of 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes an arbitrary shell command on the Qinglong server, specifying the exact resource and action. It also distinguishes from siblings by noting the host-shell scope and explicitly recommending dedicated tools like run_crons/run_script.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Only for advanced use' and 'prefer dedicated tools (run_crons / run_script) when possible.' This clearly tells the agent when to use this tool and when to choose alternatives, including naming the alternatives.
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:

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

Score Badge

Copy to your README.md:

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

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