lucky-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Each resource type has a clearly separated CRUD set, and settings/status/API catalog tools serve distinct purposes. The main ambiguity is lucky_api_call, which can theoretically overlap with the explicit CRUD tools, but it is framed as a generic catalog-driven escape hatch.
Naming Consistency4/5
The lucky_ prefix and snake_case convention are consistent, and most tools follow a verb_noun pattern like list/create/update/delete. Minor deviations exist: lucky_status uses a bare noun instead of get_status, and api_catalog/api_describe are not perfectly parallel with list/describe verbs.
Tool Count4/5
At 26 tools this is heavier than the typical well-scoped server, but the count is justified by applying the same CRUD pattern across five resource types plus settings, status, and API discovery tools. The tools are not redundant or padded; the breadth comes from the domain.
Completeness5/5
The server provides full list/create/update/delete coverage for certificates, stun rules, port forwards, web services, and DDNS, plus settings read/update, status, and an API catalog escape hatch. This covers the apparent Lucky management lifecycle without obvious dead ends.
Average 3.5/5 across 26 of 26 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false) already establish this as a non-idempotent write, and the description's 'Create' is consistent with that. Beyond the input-format hint of 'native Lucky JSON object', the description discloses no behavioral traits such as duplicate handling, whether the change takes effect immediately, or what error conditions exist. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief at 13 words in a single sentence, so it is free of fluff. However, the opening clause 'Create a Lucky port forward' largely restates the tool name, leaving only the JSON-object clause as genuinely additive information.
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 a nested free-form JSON parameter, no output schema, and zero schema description coverage, this description is far too thin for an agent to call the tool correctly. It provides no expected return value, no field guidance, and no behavior on conflict or failure, so the agent would be guessing at the input structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the sole parameter 'value' is a permissive object (additionalProperties: {}), so the schema conveys almost no meaning. The description's only contribution is the hint that the value should be a 'native Lucky JSON object', but it omits the required fields, nesting, or example shape an agent needs to construct a valid port forward definition.
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 pairs a specific verb ('Create') with a specific resource ('a Lucky port forward'), which clearly signals the operation and distinguishes it from the sibling list/update/delete port forward tools. The qualifier 'using the native Lucky JSON object' adds a hint about the input medium. However, it does not define what a port forward is or what fields it requires, so the purpose is clear but shallow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to create a port forward versus updating or deleting one, despite the sibling set (lucky_update_port_forward, lucky_delete_port_forward) making such guidance relevant. The CRUD naming implies usage by convention, but the description text itself says nothing about context, prerequisites, or alternatives.
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?
Annotations are all false and provide no positive behavioral context, so the description bears the full burden. It discloses that the tool mutates state by creating a ddns, but says nothing about side effects, idempotency, validation failures, or what happens to existing entries. The phrase 'using the native Lucky JSON object' is syntactically meaningful but not behaviorally illuminating.
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 tight sentence with no filler, and the core verb+object appears at the front. It is short but not wasteful; the problem is under-specification, not lack of conciseness.
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 create operation with one nested, undocumented object parameter and no output schema, the description leaves critical details missing: the accepted fields, required data, validation behavior, and response. The sibling tools sharing the same domain do not rescue this gap because the description itself offers no pointer to their schemas or to the Lucky API catalog/describe tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% property description coverage and the single 'value' parameter is an open object, so the description must explain the expected shape. 'Using the native Lucky JSON object' adds a small hint that the value is a Lucky-specific structure, but it does not enumerate or explain any fields, making the parameter essentially opaque to the agent.
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 states a specific verb ('Create') and a specific resource ('Lucky ddns'), so an agent can tell this is the creation operation for DDNS entries. It does not explicitly contrast with sibling list/update/delete DDNS tools, but the verb+resource combination is enough for basic identification.
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 about when this tool should be selected over siblings such as lucky_update_ddns or lucky_list_ddnss. The description only says what it does, not the conditions or prerequisites for creating a ddns, so an agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description does not need to restate that this is a mutation. However, the description adds no behavioral context beyond the word 'Create': no side effects, permission requirements, or result/return implications are disclosed.
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 with the primary action front-loaded. Every word contributes to identifying the operation, with no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single arbitrary nested object parameter, no parameter descriptions, and no output schema, the description is severely inadequate. An agent cannot determine what a 'native Lucky JSON object' is, what fields a stun rule requires, or what a successful call returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the burden of explaining the single required 'value' parameter. It only identifies it as a 'native Lucky JSON object,' which hints at the format but does not describe its structure, required fields, or any valid example.
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 states a clear verb ('Create') and resource ('Lucky stun rule'), which distinguishes it from sibling tools like lucky_update_stun_rule and lucky_delete_stun_rule. The phrase 'using the native Lucky JSON object' is somewhat ambiguous but does not obscure the core purpose.
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 about when to use this tool versus alternatives such as lucky_update_stun_rule or lucky_list_stun_rules. There are no exclusions, prerequisites, or context signals to help an agent choose this tool beyond the verb 'Create' in the description.
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?
Annotations already indicate this is not read-only, not idempotent, and not destructive, but the description adds little beyond the word 'Create'. It does not disclose what happens after creation, whether existing configurations are affected, what the response is, or any side effects. It contradicts no annotations, but it also provides minimal 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, front-loaded with the action and resource, and has no filler. It is concise, though it achieves that by omitting useful context rather than by being tightly packed with information.
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 create operation with a nested object parameter and no output schema, the description is too thin. It does not describe what fields to include in the JSON object, how the service is identified, or what success/failure looks like, leaving a gap for the agent to infer critical details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and only defines a generic 'value' object with arbitrary properties. The phrase 'native Lucky JSON object' gives a slight hint that the input must be a Lucky-specific structure, but it does not explain required keys, valid values, or expected configuration fields.
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 identifies the action ('Create') and the resource ('a Lucky web service'), which distinguishes it from sibling tools like update or delete. The phrase 'using the native Lucky JSON object' hints at the input style, but doesn't fully clarify what a Lucky web service is.
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 explicit guidance about when to use this tool versus alternatives such as lucky_update_web_service or lucky_create_certificate. The 'create' wording implies it is for new resources, but the description does not state exclusions, prerequisites, or conditions for choosing it.
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?
Annotations already cover read-only, idempotent, and destructive hints, so the description does not need to restate them. It adds a meaningful behavioral hint by requiring a 'complete native Lucky JSON object,' implying full replacement rather than a partial patch, but it gives no detail about side effects or response behavior.
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 definition is one efficient sentence with no filler, front-loading the operation and resource before the mechanism. It loses one point because the jargon phrase 'complete native Lucky JSON object' could be clearer without making the sentence longer.
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?
With a nested value object, no output schema, and 0% parameter documentation, the single sentence does not give an agent enough to construct a correct call. The description should specify or point to how the native Lucky object is shaped and what the update response is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for explaining parameters. It identifies 'key' as the lookup identifier and 'value' as the complete JSON object, but 'native Lucky JSON object' is undefined and the schema's arbitrary-object value is left under-specified.
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 states a clear verb-resource pair ('Update a Lucky stun rule') and names the key-based mechanism, which distinguishes it from the create/delete/list stun-rule siblings. It stops short of 5 because it does not explicitly contrast with create_stun_rule or state that only existing rules are targeted.
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 about when to choose this tool over update/create/delete siblings, nor any prerequisites such as first retrieving the rule via list/get. The only usage signal is the phrase 'using its key and complete native Lucky JSON object,' which describes the call shape rather than when to invoke it.
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?
The annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description simply restates 'Delete' without adding behavioral context such as whether deletion is permanent, cascading, or silently ignores missing keys.
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 wasted words. It immediately states the action, the target, and the selection mechanism.
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?
This is a simple tool with strong annotations covering the destructive and idempotent nature, so the description does not need to repeat those. However, without an output schema or explanation of the key's origin, an agent may not know enough to call it 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 only parameter is 'key', and 'by key' adds the basic meaning that the key selects which DDNS entry to delete. However, schema description coverage is 0%, and the description does not explain where the key comes from or what format it follows.
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 uses a specific verb ('Delete') and names the resource ('Lucky ddns'), with 'by key' indicating the selection method. It is clear enough to distinguish from create/update/list ddns tools, though it does not explicitly contrast with sibling delete 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?
There is no guidance about when to use this tool, prerequisites, or how it relates to alternatives such as lucky_create_ddns or lucky_update_ddns. The agent must infer usage entirely from the tool name and sibling 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 phrase 'complete native Lucky JSON object' hints that the value replaces or fully specifies the port forward, which adds some behavioral context beyond the annotations. However, it does not disclose side effects, error behavior, or whether unspecified fields are reset. No contradiction with annotations exists.
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 sentence that front-loads the action and resource, with no filler or redundant restatement. Every part contributes meaning.
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?
With no output schema, 0% parameter descriptions, and an untyped nested value object, the description is too thin for an agent to reliably construct a correct update. It lacks examples, the shape of the native Lucky JSON object, and context about how the key relates to existing resources.
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 0%, so the description must compensate. It does identify 'key' as the identifier and 'value' as a complete native Lucky JSON object, but it does not elaborate on the structure or required fields of that object, leaving the agent with only a general understanding.
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 states a specific verb ('Update') and resource ('Lucky port forward') and names the mechanism ('using its key'). It is not a mere tautology and is distinguishable from sibling tools like lucky_create_port_forward or lucky_delete_port_forward, though it does not explicitly disambiguate from them.
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 gives no guidance on when to use this tool versus the sibling create/list/delete port-forward tools. It implies usage through the verb 'Update' but does not state prerequisites, when not to use it, or any alternative selection criteria.
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?
Annotations already signal a mutating, non-destructive, idempotent operation. The description adds a useful behavioral constraint: the value must be the 'complete' native object, implying full replacement rather than a partial patch. It does not disclose failure behavior for unknown keys or invalid objects, but the annotation coverage lowers the burden.
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?
One sentence with the active verb front-loaded and no filler or repetition of the tool name. Every word contributes to describing the operation and inputs.
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 simple two-parameter update with no output schema, the description gives the operation and inputs but omits the actual shape of the value object and any error or edge-case context. Since the schema is an opaque generic object, an agent cannot reliably construct a valid value from this definition alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It maps key to the service identifier and value to the complete native Lucky JSON object, adding some meaning beyond the bare schema. However, it provides no structure, required fields, or relationship between key and value, leaving the agent to guess the object shape.
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?
States a specific action (Update) on a specific resource (Lucky web service) and names the two inputs (key and complete native Lucky JSON object). The resource name disambiguates it from sibling update tools for certificates, stun rules, port forwards, and DDNSS. 'Complete native Lucky JSON object' is somewhat jargon-heavy, but the core purpose is clear.
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 imperative 'Update a Lucky web service' makes the basic use case clear, implying use for modifying an existing service rather than creating or deleting one. However, it does not explicitly state when not to use this tool or point to alternatives such as lucky_create_web_service or lucky_delete_web_service.
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?
Annotations already indicate the operation is not read-only, not idempotent, and not marked destructive, but the description adds no behavioral context beyond 'create.' It does not mention side effects, duplicate handling, prerequisites, or validation behavior, which would be valuable for a creation 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, focused sentence with no filler. It front-loads the action and resource, making it easy to scan and understand.
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 whose only parameter is an arbitrary nested object, the description is not complete enough for an agent to construct a valid payload. There is no output schema, no field guidance, and no pointer to documentation or sibling tools like lucky_api_catalog or lucky_api_describe.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the single 'value' object and has 0% description coverage. The description labels it as a 'native Lucky JSON object,' which gives a basic hint, but it does not explain required fields, structure, or how to obtain the correct certificate 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 a specific verb ('Create') and resource ('Lucky certificate'), clearly distinguishing this tool from siblings like lucky_update_certificate, lucky_delete_certificate, and lucky_list_certificates. The phrase 'native Lucky JSON object' adds a small but relevant input distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the resource name and verb: use this when creating a certificate. However, there is no explicit guidance on when not to use it, nor any reference to alternative tools such as lucky_update_certificate or the generic lucky_api_call.
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?
The annotations already declare destructiveHint=true and idempotentHint=true, but the description adds no behavioral context beyond restating that a delete occurs. It does not disclose consequences, such as forwarding being stopped permanently, or behavior when the key 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 a single seven-word sentence with the verb front-loaded. Every word earns its place, and there is no redundant or filler 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?
For a one-parameter deletion tool, the description is minimally adequate: the key identifies the resource, and annotations cover destructive and idempotent behavior. Still, it omits useful context like obtaining the key from lucky_list_port_forwards and any error or no-op behavior, so the description is not fully 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?
With 0% schema description coverage, the phrase 'by key' provides minimal semantic value by indicating that the key is the deletion selector. However, it does not explain where the key comes from, its expected format, or how it relates to list/create operations.
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 a specific verb ('Delete'), a specific resource ('Lucky port forward'), and the selection mechanism ('by key'), making the purpose clear and distinguishing it from sibling delete tools like lucky_delete_stun_rule or lucky_delete_certificate.
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 such as lucky_update_port_forward or lucky_list_port_forwards, nor are prerequisites mentioned, such as obtaining a valid key from a prior list call. Correct usage is left 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?
The annotations already communicate that the operation is destructive and idempotent, so the description's burden is lower. It adds only that the target is identified by key, and does not mention side effects, error behavior, or irreversible consequences beyond what annotations indicate. No contradiction with annotations.
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 clear sentence with no filler. It is efficient, though it sacrifices useful operational detail that would make it fully self-sufficient.
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 one-parameter delete operation with annotations covering destructiveness and idempotency, the core call is understandable. However, it is incomplete for an agent that needs to know how to discover a valid key or what happens when the key does not exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. 'by key' indicates the single parameter is an identifier, but it does not explain the key's format, how to get it, or any constraints, leaving meaningful 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 states a specific verb ('Delete'), a specific resource ('Lucky stun rule'), and the key-based identification. This is enough to distinguish it from the many sibling CRUD tools for other resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus list/create/update stun rules, how to obtain a valid key, or any prerequisites. The intended usage is only implied by the action verb and resource 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?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is covered. The description adds no behavioral context beyond this, such as irreversibility, impact on dependent resources, authentication needs, or error 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?
A single, direct sentence with no filler or repetition. The operation and parameter role are front-loaded, 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?
For a simple delete tool, the description and annotations provide the core operation and safety profile. However, the meaning of 'key' is underspecified and there is no mention of expected output or side effects, leaving some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for the undocumented 'key' parameter. Saying the certificate is deleted 'by key' indicates the key is the identifier, but it does not explain the key's format, how to obtain it, or its domain-specific meaning.
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 a specific verb (delete), a specific resource (Lucky certificate), and an explicit identifier (key). It clearly distinguishes from sibling delete tools for other resources such as STUN rules, port forwards, web services, and DDNS.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the operation and tool name, but there is no explicit guidance on when to delete a certificate, how to obtain the key, or any prerequisites. It does not mention alternatives or exclusion conditions, so an agent must infer 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?
Annotations already carry the safety profile (mutating, idempotent, non-destructive), so the bar for added behavioral context is lower. The phrase 'complete native Lucky JSON object' adds genuine value by hinting at full-replacement semantics — the agent should send the whole object, not a partial patch. It does not, however, disclose what happens to omitted fields or whether the certificate must exist first.
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 15-word sentence with the verb and resource front-loaded and zero filler. Every word earns its place, and the mechanism ('key' + 'complete native Lucky JSON object') is packed into the same sentence without bloat.
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 write tool with a free-form nested object parameter, no output schema, and no parameter descriptions, the description is too thin. The critical unknown — the structure of the 'complete native Lucky JSON object' and where to obtain it — is unresolved, so an agent would need to discover the shape via lucky_list_certificates or api_catalog/api_describe before invoking correctly.
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?
With 0% schema description coverage, the description carries the full burden for parameter meaning, and it does map 'key' to the certificate's identifier and 'value' to the full native object. But it stops there: no hint about the key's format, how to obtain the 'complete native Lucky JSON object' (e.g., from lucky_list_certificates), or what fields that object contains.
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 states a specific verb ('Update') and resource ('Lucky certificate'), and identifies the invocation mechanism ('using its key and complete native Lucky JSON object'). It is distinguishable from siblings by the verb+resource pairing (create/delete/list for certificates, update_* for other resource types), though it never explicitly contrasts itself with lucky_create_certificate.
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?
'Update ... using its key' implies the certificate must already exist, which is a mild usage signal. No explicit when/when-not guidance or alternatives are given — lucky_create_certificate and lucky_list_certificates are never referenced, so the agent must infer the workflow from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true and idempotentHint=true, so the core safety profile is covered. The description adds no behavioral context beyond repeating the deletion, such as irreversibility, cascading effects, key provenance, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. The action and resource are front-loaded, and every word contributes to the 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?
For a one-parameter tool with no output schema and strong annotations, the description plus annotations cover the essential invocation and safety expectations. Missing details like key source and return value are minor and inferable from sibling list/create tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0% and a single required 'key' parameter, the description needed to explain the parameter's meaning. 'By key' only restates the property name and does not clarify the key format, how to obtain it, or what values are valid.
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 a specific action ('Delete') and resource ('Lucky web service'), with 'by key' clarifying the identifier used. This clearly distinguishes it from sibling delete tools for STUN rules, certificates, port forwards, and DDNS.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the name and sibling grouping: an agent can infer it is for removing a Lucky web service. However, the description gives no explicit when-to-use guidance, no exclusions, and does not reference alternatives such as list or update 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?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description does not need to restate safety. It adds context about the API source and filtering workflow, but it does not disclose output format, pagination behavior, or how the returned catalog entries should be consumed.
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 compact sentence that front-loads the primary action and resource, then adds the filtering guidance. No words are wasted, and the pointer to lucky_api_call 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?
For a simple read-only listing tool, the description is usable, especially with annotations covering safety. However, there is no output schema and no mention of what the catalog entries look like, how the limit applies, or how to map results into lucky_api_call. These gaps make it less complete than it could be.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the only place parameter meaning can be conveyed. It explains that module and side-effect are filters, but it does not explain the limit parameter or what values module should take. The sideEffect enum in the schema helps, but the description only partially compensates for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action as listing APIs and the resource as APIs discovered from the Lucky 3.0.0 web frontend. It also hints at the relationship to lucky_api_call, but it does not explicitly distinguish itself from the sibling lucky_api_describe.
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 a clear usage context: filter the catalog by module or side-effect level before using lucky_api_call. It does not explicitly state when not to use the tool or mention alternatives like lucky_api_describe, but the intended workflow is understandable.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is fully covered. The description adds no behavioral detail beyond the word 'List', such as return shape or whether all objects are returned, but it does not contradict the annotations.
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 with no filler or redundant explanation. Every word earns its place and the verb-resource structure is immediately scannable.
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 zero parameters, strong safety annotations, and a simple list operation, the description is nearly complete for correct invocation. The only gap is that it does not explicitly state the response format or that it returns all web services, but this is minor without an output schema.
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 and schema description coverage is 100%, so there is no parameter detail missing. The baseline for a no-parameter tool is high; the description correctly implies no inputs are required.
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 uses a specific verb 'List' and a clear resource 'web service objects', making it obvious this is the read-only enumeration operation for web services among the sibling tools. It could be more explicit by saying 'all' or distinguishing from create/update/delete variants, but the core purpose 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?
Usage is implied: an agent should call this when it needs to enumerate existing Lucky web service objects. However, there is no explicit guidance about when not to use it or which sibling tool is the alternative, even though the sibling names clearly include create/update/delete web service 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?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description adds no behavioral detail beyond the word 'List'. It does not mention pagination, response shape, ordering, or any side effects. With no additional behavioral context from the description, the definition relies entirely on annotations.
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, short, front-loaded sentence with no filler or redundant clauses. Every word contributes to identifying the operation and resource, even though the description is minimal.
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 zero-parameter, read-only list operation with rich annotations, the description is largely sufficient. It clearly names the resource being listed. It does not describe the return payload or note that it returns all certificates, but given the low complexity and the absence of parameters, this is a minor gap rather than a critical omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so there are no parameter semantics to document. The description does not need to compensate for any schema gaps, earning the baseline score for a parameter-free tool.
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 a specific verb ('List') and resource ('Lucky certificate objects'), clearly differentiating it from certificate create/update/delete siblings and from list tools for other resources like STUN rules or port forwards. No ambiguity about what operation it performs.
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 usage context is only implied: use this tool to list certificate objects. There is no explicit guidance about when to choose this over alternatives, nor any mention of filters, scope, or exclusions. It is not misleading, but it leaves the when-to-use decision mostly to inference.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no additional behavioral context (e.g., pagination, ordering, or scope) beyond what the annotations already provide.
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 directly states the action and resource with no filler. It is appropriately concise and 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?
For a no-parameter read-only list operation, the description communicates the core action sufficiently. However, without an output schema, it does not describe the shape or fields of the returned stun rule objects, though this may be obtainable via sibling tools like lucky_api_describe.
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 vacuously 100%, so there is nothing for the description to clarify. The baseline for a zero-parameter tool is 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 uses a specific verb ('List') and a specific resource ('Lucky stun rule objects'), clearly distinguishing it from sibling create/update/delete stun rule tools. It is unambiguous about what the tool does.
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 such as lucky_list_certificates or lucky_list_port_forwards. There is no mention of when not to use it or which sibling to choose for related needs.
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?
Beyond the annotations, the phrase 'complete native Lucky JSON object' signals that the update expects the full object, implying replacement rather than merge—a non-obvious behavioral detail. It does not contradict the idempotentHint/readOnlyHint annotations, and it adds context about what the value payload should be.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that front-loads the operation and resource. Every word contributes meaning; no filler or redundant restatement of the tool name.
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 two-parameter mutation with no output schema, the description is adequate but leaves gaps: it does not state return behavior, failure conditions, or how to obtain the 'complete native Lucky JSON object'. Sibling tools like lucky_list_ddnss exist to fill that gap, but the description does not point to them.
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 coverage is 0%, so the description must compensate. It adds meaning to 'key' as the identifier and to 'value' as a complete native Lucky JSON object, giving more guidance than the bare schema. It still leaves the exact structure of the native object unspecified, but the description provides enough directional context for an agent to know where to obtain it.
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 identifies the action ('Update') and the resource ('a Lucky ddns') clearly, and specifies the inputs ('its key and complete native Lucky JSON object'). This is enough to distinguish it from create/delete/list siblings by operation and resource, though it does not explicitly name alternatives.
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 modifying an existing DDNS entry ('Update ... using its key'), so an agent can infer when to use it relative to create/delete. However, it provides no explicit guidance on when to prefer this tool over siblings or caution about requiring a complete object rather than a partial patch.
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?
Annotations already mark the tool as destructive and not read-only. The description adds valuable behavioral context beyond annotations: arbitrary URLs are rejected and sensitive mutations are blocked in code, while all other Lucky functions remain callable. This helps set expectations without contradicting the annotations.
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, front-loaded with the core purpose, and every sentence adds meaningful constraint information. No fluff or repetition.
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 generic, destructive API-calling tool with no output schema and zero parameter description coverage, the description is too sparse. It does not mention how to discover valid catalog entries, how to interpret responseType, or when to use companion tools like lucky_api_catalog or lucky_api_describe. This leaves significant ambiguity for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not explain the meaning of body, query, responseType, or how path relates to the catalog. It only hints that paths are catalog endpoints, not arbitrary URLs. An agent still lacks enough semantic detail to confidently construct valid calls.
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?
Description states a clear verb+resource: 'Call any API present in the versioned catalog,' and explicitly rules out arbitrary URLs. This distinguishes it from the many specialized sibling tools, making its generic catalog-calling role evident.
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: use this tool for cataloged Lucky API endpoints, not arbitrary URLs, and notes that account/password/OpenToken mutations are blocked. It does not explicitly name sibling alternatives, but the exclusion of arbitrary URLs and the mention of all other functions being available imply when this generic tool should be used.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the context that the tool operates on cataloged endpoints and that the id is a catalog id, but it does not disclose error behavior, missing-id handling, or the shape of the returned description. This is acceptable 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, focused sentence: 'Describe one cataloged Lucky endpoint by catalog id.' It is front-loaded with the action and resource, contains no filler, and 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?
For a simple read-only tool with one required parameter and annotations covering safety, the description is largely complete. It tells the agent what the tool does and what the id parameter means. It could mention that catalog ids come from the sibling lucky_api_catalog tool, but that is more of a usage guideline than a correctness requirement for invoking this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only a bare 'id' string with no description (0% coverage). The description compensates by identifying the parameter as a 'catalog id', giving it meaningful role semantics. It could add more detail about where the id comes from or its format, but the core meaning is conveyed.
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 a specific verb, 'Describe', a clear resource, 'one cataloged Lucky endpoint', and the required scoping mechanism, 'by catalog id.' This distinguishes it from sibling tools like lucky_api_catalog (which likely lists endpoints) and lucky_api_call (which likely invokes endpoints).
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 catalog id is known and a single endpoint description is needed, but it does not explicitly state when to use it vs. alternatives or mention that catalog ids can be obtained from lucky_api_catalog. It provides no when-not or exclusion guidance.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered by structured metadata. The description adds no behavioral context beyond that, such as pagination, output shape, or what objects are included. It is consistent with the annotations, but doesn't add value beyond them.
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 or redundancy. The action and object are immediately clear and 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?
For a no-parameter read-only list operation with strong annotations, the description gives the essential purpose and resource. It doesn't specify the return format or pagination, but no output schema exists; nevertheless, 'List ... objects' is sufficient to invoke correctly. A slightly richer description of the returned data would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the input schema is empty, so the schema has no semantic gap for the description to fill. The baseline of 4 applies because no parameter documentation is needed. The description at least confirms the resource being listed.
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 action ('List') and identifies the exact resource ('Lucky port forward objects'). This clearly distinguishes it from the sibling create/update/delete_port_forward tools, which involve mutation rather than read-only listing.
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 intent to list rather than create/update/delete is implied by the verb and the sibling tool names, but the description does not explicitly state when to use this tool instead of alternatives or mention any preconditions. There is no direct when/when-not guidance.
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?
The description adds substantial context beyond annotations: it reveals partial-patch merge semantics (not a full overwrite) and names three protected fields that cannot be changed. This complements the annotations' idempotentHint=true and destructiveHint=false. It stops short of a 5 because the mechanics of 'prohibiting' are ambiguous—whether the patch is rejected outright or the protected fields are silently preserved.
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 sentence with zero filler. The verb and resource are front-loaded, and the critical safety constraint is delivered immediately. Every clause earns its place, and the title reinforces the safety angle with 'Safely'.
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 mutation tool with no output schema and a 0%-coverage input schema, the description covers the safety-critical invocation knowledge but leaves gaps: what happens when a protected field is included in the patch, which setting keys are valid, and what the tool returns on success or failure. The existence of lucky_get_settings as a sibling partially mitigates the missing key enumeration.
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?
With schema description coverage at 0%, the description carries the full burden and compensates well: it explains that 'patch' is a partial object merged into settings and identifies the fields that will be preserved. It does not enumerate the valid settings keys beyond the three protected ones, so an agent must infer the rest (possibly from lucky_get_settings).
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 a specific verb ('Merge'), a precise resource ('Lucky base settings'), and a defining constraint (preserving/prohibiting changes to admin account, admin password, and OpenToken). This distinguishes it unambiguously from the resource-specific sibling update tools (certificates, port forwards, web services, DDNSS) and the read-focused lucky_get_settings.
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 usage context is implied clearly: this tool modifies the global Lucky settings, not any resource-specific configuration. However, it never explicitly names alternatives or states when-not-to-use, such as 'for certificate settings use lucky_update_certificate' or 'use lucky_get_settings to read first'. An agent can infer the use case but receives no explicit routing.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description need not restate them. The description adds no additional behavioral context such as return format or pagination, so it stays at a baseline 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?
A single concise sentence states the action and the target resource with no wasted words. It is front-loaded and easy to parse.
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 zero-parameter, read-only, idempotent list operation, the description gives the essential information. The absence of an output schema means the return shape is not specified, but 'list' implies a collection of DDNS objects; still, a bit more detail about returned fields would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the schema is trivially complete, so there is nothing for the description to explain. The description's mention of listing objects is consistent with a no-input list operation.
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?
Description uses a specific verb ('List') and a specific resource ('Lucky ddns objects'), making the operation unambiguous. It clearly differs from sibling list tools for certificates, STUN rules, port forwards, and web services by naming 'ddns' as the 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The resource-specific wording implies when to use it: any time DDNS objects need to be listed. It doesn't explicitly mention alternatives, but the name and description are sufficient to rule out the other list_* tools; no exclusions are necessary for a simple read-only list.
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?
Annotations already indicate the operation is read-only, idempotent, and non-destructive, so the description is not required to restate those. It adds valuable behavioral context by disclosing that secret values are always redacted, which is not captured by the annotations or 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 two short sentences with no filler. The first sentence states the purpose clearly and the second adds the important redaction detail. Every word earns its place.
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?
For a simple parameterless read-only settings getter with comprehensive annotations, the description is complete. It covers the operation and the key output caveat (redacted secrets), and no output schema is needed to clarify an obvious return type.
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 takes zero parameters, so there is no parameter information needed. The description correctly focuses on behavior rather than parameters. This matches the baseline for a parameterless tool.
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: 'Read Lucky base settings.' This specifies a verb, resource, and scope, and differentiates it from the sibling lucky_update_settings. The redaction note adds further precision about what the tool returns.
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 reading settings, and the sibling list makes the read/write distinction apparent, but it does not explicitly state when to use this tool over alternatives or mention any exclusions. The usage guidance is adequate but left to inference.
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?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description aligns with these by saying 'Read' but does not add additional behavioral context such as authentication requirements, caching, or side effects. No contradiction exists, so this is adequate but not enriched.
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?
One short, front-loaded sentence that states the action and the three pieces of information returned. Every word earns its place; there is no fluff or redundant repetition of annotations.
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?
For a zero-parameter read-only status tool, the description is complete: it names exactly what is returned (version, system information, enabled module list) and the annotations cover safety. No output schema exists, but the description provides adequate high-level context for the agent to invoke it correctly.
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%, so no parameter documentation is needed. The description reinforces what the operation covers, which is sufficient for a no-input tool.
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 a specific verb ('Read') plus the exact resources: Lucky version, system information, and enabled module list. This clearly distinguishes lucky_status from siblings like lucky_get_settings or the CRUD tools, whose scopes differ.
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 it clear the tool is for retrieving overall Lucky status information, so an agent can infer when to use it. It does not explicitly name alternatives or exclusions, but the context is clear enough for a simple read-only status tool.
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:

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

Score Badge

Copy to your README.md:

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

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