dda-mcp-server

Server Quality Checklist

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

Latest release: v1.0.4
Disambiguation4/5
Most tools clearly specify the device type and action (e.g., alpaca_telescope_slew, open_roof). However, a few pairs like get_mount_sensors vs. get_mount_sensor_status and alpaca_switch_set vs. alpaca_switch_set_value could cause misselection.
Naming Consistency4/5
Native device tools use verb_noun (open_roof, get_device_status), while Alpaca tools follow alpaca_<device>_<action> consistently. The dual scheme is predictable, though alpaca_device_connect slightly deviates from the standard pattern.
Tool Count2/5
At 43 tools, the server far exceeds the 25-tool threshold for 'too many'. Many tools are simple status or control operations per device that could be consolidated into generic get_status or set_command functions.
Completeness4/5
The set covers discovery, connection, status, and control for all major device types (telescope, focuser, dome, camera, etc.). Minor gaps exist, such as no set_device_settings for native devices and no image retrieval for camera, but core workflows are represented.
Average 3.7/5 across 43 of 43 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under ISC 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?
With no annotations provided, the description carries the full burden of behavioral transparency. It only discloses that the response varies by device type, but fails to mention whether the operation is read-only, requires authentication, or what error behavior occurs if the device is unreachable. This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words, delivering the core purpose and a behavioral note about response variability. It is highly concise and front-loaded, with zero extraneous 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?
The tool lacks an output schema and annotations, so the description must compensate by detailing expected response types or usage context. It only notes that the response varies by device type, leaving the agent uncertain about what fields to expect or how to handle different device types. This is insufficient for a generic status 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 input schema fully documents the single 'ip' parameter with a clear description, achieving 100% schema description coverage. The tool description adds no additional semantic 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 it retrieves the current status of a Dark Dragons Astronomy device, providing a specific verb and resource. The qualifier 'Dark Dragons' helps distinguish it from Alpaca status tools, but it does not explicitly differentiate from other sibling tools like get_device_settings or alpaca_*_status variants.
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 the many status tools for specific device types. The description lacks any mention of alternatives, use cases, or contextual triggers, giving the agent no decision support for tool selection.
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, but it only restates the two operations. It does not mention idempotency, error behavior, state transitions, or whether disconnecting is safe while device operations are in progress.
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 filler or redundancy. It efficiently states the core action and leaves detailed parameter explanations to the schema.
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?
While the schema covers parameters, the tool has no annotations and no output schema, and the description does not explain expected return values, side effects, or prerequisites. For a state-changing operation, this is inadequate 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 description coverage is 100%, and every parameter already has a meaningful description, including the device_type enum and device_number default. The tool description adds no extra parameter semantics beyond loosely echoing the 'connect' parameter's 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 uses specific verbs 'Connect or disconnect' with the resource 'ASCOM Alpaca device', and the input schema's 'connect' boolean clarifies the two modes. This clearly distinguishes it from sibling tools, which focus on status queries or device-specific actions.
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. It does not mention that connecting is typically a prerequisite for device-specific commands like alpaca_camera_expose, nor does it describe when disconnecting is appropriate or any caveats.
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 mentions the connection prerequisite but does not describe what happens when the action is performed (e.g., turning the light on/off, brightness applied), potential errors, or the nature of the response. For a control tool, this is a significant transparency 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 exactly two sentences: a clear purpose statement and a critical prerequisite note. There is no redundant text or filler; every sentence earns its place. It is appropriately sized for a relatively simple tool.
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 100% schema coverage and lack of output schema, the description provides the essential purpose and a key prerequisite. However, it does not mention expected return values, failure modes, or state changes beyond 'control'. It is adequate for basic understanding but leaves the agent to infer runtime behavior, which is a clear gap for a tool with no annotations.
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 schema fully documents all parameters including brightness and device_number. The description adds no parameter-specific meaning beyond the schema; its only extra context is the external connection prerequisite, which is not tied to any individual parameter. Baseline 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 states the tool 'Control an ASCOM Alpaca cover calibrator light', which clearly identifies the verb (control) and the resource (cover calibrator light). It distinguishes from sibling tools like 'alpaca_covercalibrator_cover' by specifying 'light', though 'control' is somewhat generic without listing the specific actions (on/off) that appear in the schema.
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 provides a prerequisite note: 'Device must be connected first using alpaca_device_connect.' This gives a clear condition for use but does not explicitly contrast with alternatives (e.g., using status tools) or specify when not to use it. Usage is implied rather than fully elaborated.
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 notes a connectivity prerequisite and the basic actions. It does not explain the 'halt' action, potential side effects, error conditions, or confirmation behavior for a hardware-mutating 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 extremely concise—two sentences, front-loaded with the purpose, then a necessary prerequisite note. No filler 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?
For a simple tool, it provides the key prerequisite and purpose, but lacks explanation of the 'halt' action and any return/error behavior. With no annotations or output schema, this leaves the agent with some ambiguity about invoking success or handling failures.
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 all parameters are documented in the schema. The description adds no additional parameter meaning beyond stating the open/close intent and the connection prerequisite; it does not clarify the 'halt' action or device_number semantics beyond what the schema already provides.
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 resource (ASCOM Alpaca cover calibrator cover) and the primary actions (open or close). It distinguishes from sibling tools like alpaca_covercalibrator_status and alpaca_covercalibrator_calibrator, though it omits the 'halt' action from the schema.
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 provides a clear prerequisite (device must be connected first) but does not offer explicit guidance on when to use this tool versus alternative cover/calibrator tools or when not to use it. The connection note is useful context but does not cover alternatives.
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 behavioral disclosure burden. It adds a useful prerequisite (must connect first) but does not mention side effects, irreversibility, or error behavior. The prerequisite adds value, but the description remains sparse for a state-changing 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 concise and front-loaded: one sentence for purpose, one for the prerequisite note. No wasted words, and the structure is effective.
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 simple tool and full schema coverage, the description is mostly complete. However, it misses the distinction between this boolean state setter and alpaca_switch_set_value (which likely handles analog values), and it doesn't indicate any return values or error conditions. The prerequisite note is helpful but doesn't fully cover the 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?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no extra meaning beyond what the schema already provides, 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 ('Set the state of a switch') and the resource ('ASCOM Alpaca switch device'). It distinguishes itself from status and value-setting siblings by using 'state' rather than 'value' or 'status', though it doesn't 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only guidance is a prerequisite note that the device must be connected first. It does not explain when to use this tool versus alpaca_switch_set_value or other switch-related tools, nor does it provide any exclusions or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals no behavioral details beyond the basic action. It does not mention whether the command is synchronous, potential delays, safety considerations, or failure modes. With no annotations available, the description carries the full burden but provides minimal insight.
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 nine-word sentence that directly states the action. It is front-loaded, efficient, and contains no filler 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?
The description is minimally adequate for a simple one-parameter tool, but it lacks contextual information about prerequisites (device connectivity), expected behavior, or distinctions from nearby tools. It leaves the agent to infer operational details.
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 fully documents the single 'ip' parameter with a clear description (100% coverage), so the description does not need to add parameter details. It adds no extra meaning beyond the schema, yielding the baseline score.
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 ('Close the observatory roof') on a specific resource ('DragonLAIR device'), distinguishing it from siblings like open_roof and abort_roof by its verb. It is not a tautology and provides a precise, actionable 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 provided on when to use this tool versus alternatives like open_roof or abort_roof. The usage is only implied by the verb 'close', but the description lacks any context, prerequisites, or explicit 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 must carry the full behavioral burden. It only states the basic action and purpose, without disclosing return format, side effects, or prerequisites beyond the IP address. The read-only nature is inferred but not stated.
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, front-loaded with the core action and a helpful purpose explanation. Every word earns its place with no 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?
For a simple one-parameter getter, the description covers the basic purpose. However, the lack of an output schema and no clarification of the relationship to the similar 'get_mount_sensor_status' leave gaps in completeness.
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 the sole parameter 'ip', so the schema already fully documents it. The description mentions 'DragonLAIR device' but adds no new meaning beyond the schema, warranting the baseline score.
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 verb ('Get') and resource ('status of mount sensors') and explains their purpose. However, it does not distinguish from the very similarly named sibling tool 'get_mount_sensor_status', so it misses the differentiation criterion.
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 second sentence implies this tool is relevant for checking roof movement safety, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. The 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.
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 'Abort the current roof operation' without explaining consequences such as what happens if no operation is running, whether the abort is immediate, or any error semantics. This leaves significant behavioral ambiguity for an agent.
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 of nine words. It contains no filler or redundant information, making it appropriately concise and well-structured for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the low complexity and single parameter, this is a mutation tool with no annotations and no output schema. The description omits important contextual details such as when the abort is valid, error behavior, or any safety implications. It does not adequately equip an agent to use the tool 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 input schema contains a single parameter 'ip' with a full description, giving 100% schema coverage. The tool description adds no additional parameter semantics or context, so the baseline score of 3 applies since the schema already documents the parameter adequately.
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 'Abort' with a clear resource 'current roof operation' on a 'DragonLAIR device', which unambiguously states the tool's function and differentiates it from siblings like open_roof and close_roof. It precisely identifies the action and target.
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 should be used when a roof operation is in progress, but it provides no explicit guidance on when to use it versus alternatives, nor any exclusions or prerequisites. The usage context is only implied by the phrase 'current roof operation', not clearly stated.
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 disclose behavioral traits but only states the action. It does not mention whether the operation is synchronous, what happens if the roof is already open, or any side effects. This leaves important behavioral ambiguity.
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, efficiently-phrased sentence that directly conveys the purpose without any wasted words or unnecessary elaboration.
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?
The tool is simple with one parameter, but the absence of an output schema and annotations means the description should provide information about return values, blocking behavior, or error conditions. It does not, leaving the agent uncertain about what to expect after 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 input schema already provides a clear description for the single 'ip' parameter ('IP address of the DragonLAIR device'), so the description does not need to add parameter details. The baseline of 3 applies because schema coverage is high and the description 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 action (open) and the resource (observatory roof on a DragonLAIR device). It distinguishes itself from sibling tools like close_roof and abort_roof by specifying the exact 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 usage is implied: use this tool when you want to open the roof on a DragonLAIR device. However, it provides no explicit guidance about when not to use it, preconditions, or mention of alternatives such as close_roof for the opposite action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the action and connection prerequisite but does not disclose whether the operation blocks, returns immediately, handles errors, or has side effects. This is insufficient for a mutating 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 long, front-loaded with the primary action, and includes a necessary prerequisite note. Every word earns its place with no 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?
The tool is simple with a well-covered schema, and the description provides purpose and prerequisite. However, it lacks behavioral details like return behavior or error handling, and there is no output schema to fill that gap, making it adequate but 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?
Schema description coverage is 100% and all parameters are documented in the input schema. The description adds no parameter-specific information 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool opens or closes an ASCOM Alpaca dome shutter with a specific verb and resource. This distinguishes it from sibling tools like alpaca_dome_status (status) and alpaca_dome_slew (slewing), as well as open_roof/close_roof which target a different structure.
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 the tool (to open/close the dome shutter) and provides a prerequisite (device must be connected first via alpaca_device_connect). However, it does not mention alternatives or explicitly state when not to use this tool, so it only partially covers usage 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?
No annotations are provided, so the description must disclose behavioral traits. It mentions the connection prerequisite but fails to explain error handling, idempotency, or side effects of moving the filter wheel. For a mutating operation, 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 two sentences, with the main purpose front-loaded. The note about connecting first adds necessary context without waste. 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?
The schema fully covers parameters and the note addresses the key prerequisite. However, with no output schema and no annotations, the description does not explain return values or failure modes, leaving it minimally viable for a simple setter 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 input schema provides complete descriptions for all four parameters (100% coverage), including 'position' being 0-indexed. The description adds no additional parameter meanings beyond what the schema already documents.
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 clear verb+resource: 'Set the position of an ASCOM Alpaca filter wheel.' This distinctly identifies the tool's function and differentiates it from siblings like alpaca_filterwheel_status, which reads status rather than setting position.
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 includes a valuable prerequisite ('Device must be connected first using alpaca_device_connect'), implying when to use the tool. However, it does not explicitly discuss when not to use it or compare it to alternatives, so usage guidance remains partially implied.
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 a key behavioral requirement (device must be connected) and implies read-only operation. It does not mention return format, error conditions, or side effects, but for a status getter this is 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?
Two concise sentences with no filler. It states the purpose and the one critical prerequisite. 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 read-only status tool, the description is adequate but thin. It doesn't mention what the returned data structure looks like, possible error cases, or whether device_number applies to multiple focusers. With no output schema and no annotations, more detail would help, but the tool is relatively straightforward.
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 all three parameters (ip, port, device_number) already described. The description adds no parameter-specific meaning beyond the schema, so the baseline 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 ('Get the status') and the resource ('ASCOM Alpaca focuser'), and enumerates specific data points (position, temperature, movement state). It is specific enough to differentiate from other status tools like alpaca_telescope_status, though it doesn't explicitly name a sibling.
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 clear prerequisite ('Device must be connected first using alpaca_device_connect'), which is helpful context. However, it provides no explicit guidance on when to use this tool versus alternatives like get_device_status or other alpaca_*_status tools. Usage is implied rather than stated.
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 the action and the connection prerequisite, but does not mention potential error conditions, whether the switch must support writes, reversibility, or what the response indicates. For a mutation tool, this lack of detail 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 two sentences, action-first, and contains no redundant information. Every word earns its place, including the prerequisite note.
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 relatively simple setter with well-documented schema, the description includes the essential prerequisite and is reasonably complete. However, it omits any return value expectation, does not clarify the meaning of 'value', and the existing sibling 'alpaca_switch_set' creates potential confusion that the description does not resolve.
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% coverage with descriptions for all five parameters, so the baseline is 3. The description adds no extra semantic meaning about the parameters, such as what 'value' represents (e.g., boolean vs. numeric range) or how 'switch_id' maps to physical switches.
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 ('Set the value of a switch') and the resource ('ASCOM Alpaca switch device'), making the core purpose unambiguous. However, it does not distinguish itself from the similarly named sibling tool 'alpaca_switch_set', which appears to serve an overlapping function.
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 provides a required prerequisite: 'Device must be connected first using alpaca_device_connect', which gives clear context for when the tool can be invoked. It does not, however, discuss alternatives or exclusions, such as when alpaca_switch_set would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral transparency. It only states the action without disclosing side effects, persistence, authentication requirements, or error behavior. 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, front-loaded with the action and object. It contains no wasted words, making it easily parsable by an agent.
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 low complexity (two simple parameters, no output schema) and complete schema coverage, the description is mostly sufficient, but it lacks context about behavior after invocation (e.g., whether the panel must be on, if there is a response). This leaves some ambiguity for a mutation 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 input schema already documents both ip and brightness with descriptions and validation, yielding 100% coverage. The description adds no additional semantics beyond what the schema provides, so 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 'Set' and identifies the resource 'brightness of a DragonLIGHT flat panel light', clearly distinguishing it from sibling tools like turn_on_flat_panel or get_flat_panel_status.
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 its usage—when you need to adjust brightness—but doesn't explicitly state when to use it versus toggling power, nor any prerequisites such as the panel being on. It provides no alternative tool mentions.
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 the connection prerequisite, but does not disclose important behavioral traits such as whether the exposure is asynchronous, whether it returns immediately, or how to monitor completion.
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 with the main purpose front-loaded. The note about connection is relevant and not redundant. No fluff present.
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 no annotations and no output schema, the description is too sparse. It does not mention typical exposure workflow details like asynchronous execution or polling with alpaca_camera_status, leaving a significant gap in actionable 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 has 100% description coverage for all parameters, so the baseline is 3. The description adds no additional parameter-specific meaning 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 states 'Start an exposure on an ASCOM Alpaca camera' with a specific verb and resource, clearly distinguishing this from sibling camera tools like status, cooler, or abort operations.
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?
It provides a clear prerequisite: 'Device must be connected first using alpaca_device_connect.' This tells the agent a condition for use, though it does not explicitly mention alternatives or when not to use the tool.
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. 'Get' implies a read-only operation, but the description does not explicitly state that it does not modify device settings, nor does it disclose possible errors or authentication needs. It does add scope by listing setting categories, which is useful but limited.
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, and every word earns its place. It is concise and well-structured, with no 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?
For a simple getter with one parameter and no output schema, the description covers the core purpose and the types of settings returned. It does not explicitly describe the return format, but the list of setting categories (safety, location, motor) provides reasonable completeness. A clear gap is the relationship to similar sibling tools.
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 documents the single 'ip' parameter with a clear description ('IP address of the DragonLAIR device'), achieving 100% coverage. The tool description does not add any additional meaning beyond the schema, so the baseline 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 uses a specific verb 'Get' and a resource 'current settings of a DragonLAIR device', and lists content categories (safety configuration, location, motor settings). This makes the purpose clear, but it does not distinguish itself from the sibling tool 'get_device_status', which could be confused for a similar 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 description implies usage through the action 'Get', but provides no explicit guidance on when to use this tool versus alternatives like 'get_device_status' or other status-related tools. There are no exclusions or references to alternative 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 must carry the full burden of behavioral disclosure. It only states the action 'turn off' without detailing side effects, idempotency, error behavior, or any safety considerations. For a state-changing tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, achieving maximum conciseness while remaining clear and 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 one-parameter tool, the description adequately conveys the primary function. However, it does not mention return values or error conditions, which would be useful for an operation with no output schema. Still, it is better than minimum viable given the simplicity.
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 sole parameter 'ip' is complete ('IP address of the DragonLIGHT device'). The tool description adds no additional meaning beyond what the schema already provides, 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 verb 'turn off' and the resource 'DragonLIGHT flat panel light', making it distinct from sibling tools like turn_on_flat_panel and set_flat_panel_brightness. It is specific and 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?
No explicit guidance on when to use this tool versus alternatives, but the purpose is clear enough that usage is implied (e.g., use when you want to turn off the light). Lacks any additional context about 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action 'turn on' but does not disclose whether the command is asynchronous, idempotent, requires network reachability, or what errors might occur. This leaves the agent without critical 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?
The description is a single concise sentence with no redundant words. It is front-loaded with the action and resource, communicating the purpose in an efficient manner.
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), the description is complete enough for basic invocation. It states the action clearly, and the schema covers the parameter. However, it lacks any caveats or prerequisites, potentially leaving room for errors, but for a simple on/off command this is generally acceptable.
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 'ip' parameter as 'IP address of the DragonLIGHT device' with 100% coverage. The description adds no additional meaning or context about parameters, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Turn on') and clearly identifies the resource ('DragonLIGHT flat panel light'), which precisely defines the tool's function. This clearly distinguishes it from sibling tools like turn_off_flat_panel, set_flat_panel_brightness, and get_flat_panel_status.
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 from the verb 'turn on' but provides no explicit guidance about when to use this tool versus alternatives. It does not mention checking status first or any prerequisites, making the guidance implicit 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?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It states the prerequisite (connection) but does not explain what happens on halt (e.g., whether it's immediate, whether it returns a success/failure indicator, or any side effects). For a control command, 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, direct sentence plus a useful note. Every word earns its place: it states the operation, the resource, and a critical prerequisite without fluff.
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 halt command, the description is adequate: the schema covers parameters and the note covers the main prerequisite. However, the absence of any information about the command's effect (e.g., whether it is a blocking call or what response to expect) leaves some gaps, especially given no output schema or annotations.
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% documentation coverage for all three parameters (ip, port, device_number). The description adds no parameter-specific information beyond the schema, so the 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 clearly states the action ('Halt') and the resource ('ASCOM Alpaca focuser'), which exactly matches the tool name. It distinguishes itself from sibling tools like alpaca_focuser_move and alpaca_focuser_status by specifying the halt operation.
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 includes an explicit prerequisite: 'Device must be connected first using alpaca_device_connect.' This provides clear context for when the tool is valid. It doesn't mention alternative tools for other focuser operations, but the name and purpose make the intended use obvious.
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 notes the connection prerequisite, but fails to mention that this is a mutating operation that changes telescope state, potential side effects, or how completion is signaled. This is a significant gap for a write-like command.
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 concise sentences: the first states the action, the second provides a necessary prerequisite. There is no redundant wording 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?
The description covers the purpose and a key prerequisite, but since there is no output schema, it does not explain what the caller can expect upon completion (e.g., success indicator or error behavior). This leaves some ambiguity for a mutating operation.
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 describes all parameters with 100% coverage, including the 'action' enum and default for 'device_number'. The description adds no additional parameter details, 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 ('Park or unpark') and the resource ('ASCOM Alpaca telescope'), which is specific and distinct from sibling telescope commands like slew, tracking, or abort.
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 a clear prerequisite ('Device must be connected first using alpaca_device_connect'), giving useful context on when it can be used. It does not explicitly mention alternatives, but the purpose is self-evident and the prerequisite guides usage.
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 of behavioral disclosure. It discloses that the tool reads and returns status (non-destructive), but it does not mention potential failure modes (e.g., unreachable IP), timeout behavior, or whether any special permissions are required. For a simple getter, this is minimal but adequate.
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 concise two-sentence structure that front-loads the action and resource, and every sentence adds value: one states what the tool does, the other summarizes the return content. There is no redundancy or waste.
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 a single parameter and no output schema, the description still covers the essential behavior by stating what is returned (on/off state, brightness, device info). The mention of 'device info' is somewhat vague, but for a status getter, the description provides sufficient context to understand the tool's output and purpose.
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 includes a clear description for the only parameter 'ip' ('IP address of the DragonLIGHT device'), providing 100% schema coverage. The tool description adds no further parameter-level details, 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.
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 explicitly names the resource ('status of a DragonLIGHT flat panel controller'), and it lists the returned data (on/off, brightness, device info). This clearly distinguishes it from sibling control tools like turn_on_flat_panel and the generic get_device_status, making the purpose unmistakable.
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 a read-only status check through the verb 'Get' and the return-focused wording, which provides clear context for when to use it. However, it does not explicitly state when not to use it or name alternatives, such as get_device_status for broader device status, so it lacks explicit usage 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?
No annotations are present, so the description carries the full burden. It mentions the connection prerequisite, which is a behavioral condition. However, it does not explicitly indicate that the operation is read-only or describe error behavior (e.g., if not connected), leaving some transparency 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 sentence plus a note, with no wasted words. It is front-loaded with the action and includes a relevant prerequisite. Highly concise and well-structured.
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 description explains what is returned (cover and calibrator state) and mentions the connection requirement. However, without an output schema or annotations, it does not detail possible state values, return format, or error conditions. For a status tool this is adequate but could be richer.
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 covers 100% of parameters with descriptions (ip, port, device_number). The description does not add additional parameter information, but given the high schema coverage, 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 states it 'Get the status' of an ASCOM Alpaca cover calibrator, specifying it includes cover and calibrator state. This distinguishes it from sibling tools like alpaca_covercalibrator_cover and alpaca_covercalibrator_calibrator, which likely control rather than read state.
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 a clear prerequisite: 'Device must be connected first using alpaca_device_connect.' This is useful guidance. It doesn't explicitly state when to use this instead of alternative status tools, but the tool's purpose is well understood from the name and description.
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 of behavioral disclosure. It notes the connection prerequisite, which is valuable, but does not detail other behaviors such as what happens if the device is already halted, whether the command is asynchronous, or error handling. This is borderline sufficient for a simple halt 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 extremely concise: two short sentences. The first sentence delivers the purpose, and the second adds a critical prerequisite. No wasted 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 halt command with no output schema, the description is adequate but incomplete. It explains the purpose and a prerequisite, but does not discuss return values or error conditions. Given the low complexity and full schema coverage, this is acceptable but not exceptional.
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% coverage for all three parameters (ip, port, device_number), each with a description. The tool description adds no additional parameter-specific meaning beyond that, 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.
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: 'Halt an ASCOM Alpaca rotator.' This specifies a definite action (halt) and a clear resource (rotator), distinguishing it from sibling tools like alpaca_rotator_move and alpaca_rotator_status.
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 a critical usage prerequisite ('Device must be connected first using alpaca_device_connect'), giving clear context for when this tool can be invoked. It does not explicitly mention exclusions or alternatives, but the purpose statement implies the primary 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 full burden. It discloses that the operation is a read ('get') and adds the connection prerequisite, which is helpful. However, it does not describe the return format, error behavior, or what constitutes 'status', leaving some behavioral ambiguity.
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 action, and contains no unnecessary words. The prerequisite note is directly relevant and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema documents all parameters, but with no output schema, the description could usefully hint at what the status contains (e.g., safe/unsafe states). The prerequisite is helpful, but return value semantics are not addressed, leaving a gap for an agent that needs to interpret results.
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 each parameter having a clear description. The tool description does not add anything beyond the schema, so the baseline score 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 ('Get the status') and the specific resource ('ASCOM Alpaca safety monitor'), distinguishing it from sibling status tools for other device types. The verb+resource pattern is specific and 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 note 'Device must be connected first using alpaca_device_connect' provides clear context and a prerequisite for usage, which is valuable. It does not mention alternatives or exclusions, but the purpose is specific enough that the agent can infer when to use it (e.g., for safety monitor status queries).
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 must bear the burden of behavioral disclosure. It mentions the need for prior connection and coordinate systems, but does not disclose whether slew is synchronous, what errors might occur, or any side effects. This is a moderate gap for a control 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 two sentences, front-loaded with the primary action and followed by a crucial note. Every word earns its place; no fluff.
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 has 7 parameters and no output schema or annotations. The description covers the core action and connection prerequisite but leaves ambiguity about parameter combinations (both RA/Dec and Alt/Az provided?) and expected return behavior. For a moderate-complexity control tool, this is adequate but has clear 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 description coverage is 100%, so the schema already documents all seven parameters in detail. The description adds only the concept of coordinate systems (RA/Dec or Alt/Az) but doesn't clarify how parameters interact (e.g., whether both pairs are required mutually exclusive). This is minimal added value 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 clearly states the action 'slew' and the resource 'ASCOM Alpaca telescope', with coordinate specification (RA/Dec or Alt/Az). This distinguishes it from sibling tools like status, park, tracking, and abort.
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 a key prerequisite: 'Device must be connected first using alpaca_device_connect.' This gives clear context for when to use the tool, though it doesn't explicitly contrast with alternatives. The verb 'slew' inherently differentiates from other telescope actions.
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 burden of behavioral disclosure. It reveals the connection prerequisite, which is valuable, but does not describe error behavior, side effects, or whether the abort is immediate. The key prerequisite is a positive addition.
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: the first states the purpose, the second adds a necessary note. No waste, 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?
Despite no output schema, the tool is simple. The description covers the action, resource, and a key prerequisite. Given the complexity, it is sufficiently complete for an agent to invoke it 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?
Schema description coverage is 100%, so the parameters (ip, port, device_number) are fully documented in the schema. The description adds no extra parametric meaning, but the baseline of 3 is appropriate since the schema handles 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 'Abort' with a clear resource 'exposure on an ASCOM Alpaca camera'. It distinguishes itself from sibling abort tools like 'abort_roof' and 'alpaca_telescope_abort' by explicitly scoping to camera exposure.
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 an explicit prerequisite: 'Device must be connected first using alpaca_device_connect.' This gives clear context for when the tool can be used. It doesn't mention alternatives explicitly, but the sibling list and resource-specific language make the use case evident.
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 usefully notes the connection prerequisite, but it doesn't state the effect of the operation (e.g., turning the cooler on/off, setting temperature) or potential failure modes. The verb 'control' combined with schema parameter hints provides some transparency, but not full.
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 only two sentences, front-loaded with the core purpose and immediately followed by a necessary prerequisite. There is zero wasted text 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?
For a simple setter tool with comprehensive parameter descriptions and no output schema, the description covers the essential purpose and prerequisite. It could add that the operation is a direct command with no return value detail, but it's complete enough for an agent to invoke the tool 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?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific details beyond what the schema already provides; it only mentions the prerequisite. This makes it adequate but not enhanced.
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 'control' and resource 'cooler on an ASCOM Alpaca camera,' clearly identifying the tool's purpose. It distinguishes itself from sibling tools because no other tool targets the camera cooler.
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 an explicit prerequisite: the device must be connected first via alpaca_device_connect. This helps the agent know the correct call order. It doesn't mention alternatives or when-not to use it, but the context is clear.
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 of behavioral disclosure. It states the action and the connection prerequisite, which is helpful. However, it does not disclose whether the operation is blocking, what happens if the device is not connected, or how to verify the slew completion (e.g., via alpaca_dome_status). More behavioral 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 extremely concise: two short sentences. The first sentence front-loads the core purpose, and the second adds the essential prerequisite. Every word earns its place, and no filler is present.
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 command with a well-covered schema, the description covers the essential context: what the tool does, the target parameter, and the required precondition. It could be more complete by mentioning return values or error behavior, but the lack of an output schema is mitigated by the tool's simplicity.
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 does not add extra meaning beyond the schema; the only addition is the connection prerequisite, which is not parameter-specific. Thus, no additional parameter semantics 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 clearly states the tool's function with a specific verb ('Slew'), resource ('ASCOM Alpaca dome'), and target ('specific azimuth'). It distinguishes from sibling tools like alpaca_dome_status and alpaca_dome_shutter, making its unique 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 provides a clear usage prerequisite: the device must be connected via alpaca_device_connect. This gives context for when the tool can be used. It does not explicitly state alternatives or exclusions, but the prerequisite is a strong guideline.
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 of behavioral disclosure. It adds the important connection requirement, which is a useful behavioral trait. However, it does not explicitly state that the operation is read-only or describe what happens if the device is not connected, leaving some gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the main purpose statement and a note about the prerequisite. It is front-loaded with the primary purpose and every word contributes value without 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?
For a status retrieval tool with no output schema and no annotations, this description is fairly complete. It specifies the purpose, the key status elements (shutter state, position, slewing status), and the connection prerequisite. It does not mention error handling or return format, but these are less critical for a read-only status 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?
All three parameters (ip, port, device_number) have descriptions in the input schema, giving 100% schema description coverage. The tool description does not add additional information about these parameters beyond what the schema already provides, so the 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 the specific verb 'Get' and identifies the exact resource ('status of an ASCOM Alpaca dome'). Listing shutter state, position, and slewing status clearly differentiates this tool from sibling status tools like alpaca_focuser_status or alpaca_telescope_status.
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 a prerequisite: 'Device must be connected first using alpaca_device_connect.' This gives the agent clear context for when to use this tool (after connection). However, it does not mention alternatives or cases where a different tool would be more appropriate, so it lacks explicit exclusions.
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 connection requirement and hints at output contents, but does not explicitly state that this is a safe/read-only operation or describe error conditions. The status-getter context implies non-mutating behavior, but the description could be more explicit.
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 short sentences, front-loaded with the main purpose. Every word adds value: the first sentence states the function, the second provides a crucial prerequisite. No redundancy or 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?
For a simple read-only status tool with 100% schema coverage, the description is adequate. It specifies the key output elements (current position and available filters) and the connection prerequisite. The absence of an output schema is partially compensated by listing the main return fields, though more detail on error cases or return format would improve completeness.
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 complete descriptions for all three parameters (ip, port, device_number), so the description does not need to add parameter-level detail. It adds no extra semantics beyond what the schema already covers, warranting the baseline score 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 provides a specific verb ('Get') and resource ('ASCOM Alpaca filter wheel'), and further clarifies the scope by listing 'current position and available filters.' This clearly distinguishes it from sibling status tools for other devices.
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 a prerequisite: 'Device must be connected first using alpaca_device_connect.' This gives clear usage context. It does not explicitly exclude alternatives, but the device-specific nature of the tool makes its use case obvious.
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 behavioral disclosure. It adds the connection prerequisite but does not disclose whether the command blocks until movement completes, what errors occur if not connected, or what the return value means. This is minimal but useful 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?
Two concise sentences: the first states purpose, the second provides the key prerequisite. Every word earns its place, and the main action 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 command with full schema coverage and no output schema, the description covers the core purpose and a critical prerequisite. It lacks details on return values or error handling, but those are not explicitly needed given the tool's simplicity and the richness of the 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?
Schema description coverage is 100%, so the schema fully documents the parameters (ip, port, position, device_number). The description adds no parameter-specific details beyond the schema, meeting the baseline for full coverage.
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 ('Move an ASCOM Alpaca focuser to a specific position') with a specific verb and resource, and it distinguishes itself from sibling tools like alpaca_focuser_status (read-only) and alpaca_focuser_halt (stop movement).
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 a clear prerequisite ('Device must be connected first using alpaca_device_connect') which is important usage context. However, it does not explicitly mention when not to use the tool or name alternatives like alpaca_focuser_halt for stopping.
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 states the action and the connection requirement, but does not detail potential side effects, blocking behavior, or error conditions. The note adds useful context, yet the description remains minimal for a mutating 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 the primary action front-loaded and the critical note following. Every word earns its place, making it highly concise and scannable for an agent.
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 move command with all parameters documented in the schema, the description covers the essential usage context (connection prerequisite) and the main action. It does not explain return values, but no output schema is expected. Overall, it is sufficiently complete for its 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?
Schema description coverage is 100%, so all parameters are already documented. The description adds no additional parameter semantics beyond what the schema provides. The baseline score of 3 is appropriate as the schema handles parameter 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 'Move an ASCOM Alpaca rotator to a specific position' uses a specific verb and resource, clearly distinguishing it from sibling tools like alpaca_rotator_status (which reports status) and alpaca_rotator_halt (which stops movement). It precisely conveys the tool's function.
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 includes a clear prerequisite: 'Device must be connected first using alpaca_device_connect.' This provides actionable usage context without explicitly naming alternative tools, but it adequately tells the agent when this tool can be invoked.
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 for behavioral disclosure. It implies a read-only operation ('Get') and mentions the prerequisite connection, but does not disclose error behavior, return format details, or other side effects. 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 two sentences, front-loaded with purpose and specifics, and contains no fluff. It effectively communicates the core information in a minimal structure.
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 getter with no output schema, the description adequately covers purpose and prerequisite. It mentions key return fields ('position and movement state'), which provides enough context for an agent to invoke the tool correctly. A bit more detail on return structure would be helpful, but it 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 coverage is 100%, so all parameters (ip, port, device_number) are described in the schema. The description does not add meaning 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's purpose with a specific verb ('Get') and resource ('ASCOM Alpaca rotator'), and details what it returns ('position and movement state'). It distinguishes itself from sibling status tools by naming 'rotator'.
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 a prerequisite note: 'Device must be connected first using alpaca_device_connect.' This gives clear context for when the tool can be used, though it does not explicitly mention alternatives or when not to use it. The prerequisite is valuable guidance for an agent.
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 behavioral disclosure. It notes the connection prerequisite, which is helpful, and implies a read-only operation via the verb 'Get.' However, it does not describe the return format (e.g., array of switch states), potential errors if not connected, or other side effects, leaving some behavioral aspects unspecified.
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 exceptionally concise: two short sentences, with the primary action front-loaded and the important prerequisite clearly appended. 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?
For a straightforward status-read tool with no output schema and no annotations, the description provides adequate high-level context: what it does and the key precondition. It does not detail the return structure, but this is not critical for a simple status check, and sibling tools imply a common pattern for status endpoints.
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% description coverage for all three parameters (ip, port, device_number), so the schema already explains parameter semantics. The description adds no additional parameter-specific information, maintaining the baseline score 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 function: 'Get the status of all switches on an ASCOM Alpaca switch device.' It uses a specific verb ('get'), identifies the resource ('all switches'), and distinguishes itself from sibling tools like alpaca_switch_set (which changes states) and other status tools by explicitly mentioning 'switch device.'
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 includes a crucial usage prerequisite: 'Device must be connected first using alpaca_device_connect.' This provides clear context on when the tool can be used. However, it does not explicitly contrast with alternatives or mention when not to use it, so it stops short of a 5.
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 discloses the connection prerequisite, which is useful behavioral context. However, it doesn't mention side effects, error behavior when no slew is in progress, or whether the action is idempotent. Given the absence of annotations, more detail about expected behavior would be valuable.
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 long, front-loaded with the primary action, and the connection note is a meaningful addition. There is no wasted text or repetition of 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?
For a simple action tool with no output schema, the description provides the essential information: what it does and a key prerequisite. It could improve by indicating what happens if no slew is in progress or mentioning potential error conditions, but overall it is sufficiently complete for straightforward 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%, with all three parameters (ip, port, device_number) already described. The tool description adds no additional parameter-level detail, so the baseline of 3 is appropriate—the schema handles parameter documentation adequately.
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 ('Abort any slew in progress'), the resource ('ASCOM Alpaca telescope'), and the scope ('any slew in progress'). It distinguishes this from siblings like alpaca_telescope_slew and alpaca_telescope_park by focusing on aborting an in-progress movement.
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?
It gives a clear usage context: use when a slew is in progress and you want to stop it. The note about needing to connect the device first provides a tangible prerequisite. However, it doesn't explicitly mention alternatives or exclusions (e.g., using alpaca_camera_abort for camera operations), but the tool name and description make the appropriate situation clear.
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 discloses the prerequisite (connection required) and implies a read-only operation via 'Get', but it does not explicitly state that it is side-effect free, nor does it describe error behavior or any additional constraints.
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: the first states the purpose and return fields, the second gives a prerequisite. It is front-loaded, clear, and every word earns its place without 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?
There is no output schema, but the description lists key return data (position, tracking, slewing) and warns about the connection prerequisite. For a simple status tool with three parameters, this is sufficiently complete, though it could additionally describe the structure of the returned status object.
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 parameters (ip, port, device_number), so the schema already explains the parameter semantics. The description adds operational context about needing connection, but does not add new parameter-level 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 uses the specific verb 'Get' with the resource 'status of an ASCOM Alpaca telescope' and lists key components (position, tracking state, slewing status). This clearly distinguishes it from sibling status tools for other devices such as alpaca_focuser_status or alpaca_dome_status.
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 for when to use the tool (to retrieve telescope status) and includes a critical prerequisite: the device must be connected first using alpaca_device_connect. It does not explicitly mention alternative tools or when not to use it, but the purpose is unambiguous.
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 transparency burden. It discloses a key prerequisite (connection) but does not mention permissions, side effects, or behavior if the device is not connected. For a mutation tool, this is minimal but not misleading.
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 plus a note, concise and front-loaded with no superfluous 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 boolean setter with full schema coverage, the description covers the essential context (connection prerequisite). It lacks details on return values or error behaviors, but given the tool's simplicity, 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?
Schema description coverage is 100%, so the baseline is 3. The description does not add additional parameter semantics beyond what the schema already provides.
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 ('Enable or disable tracking') on a specific resource ('ASCOM Alpaca telescope'), using a specific verb. It distinguishes from sibling telescope tools like slew, park, abort, and status.
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 includes a prerequisite note ('Device must be connected first using alpaca_device_connect'), providing clear context for usage. However, it does not explicitly mention when to use this tool over alternatives or any exclusions.
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 burden of behavioral disclosure. It adds the useful detail that discovery happens via UDP broadcast, which is a specific network behavior. However, it does not mention the return format, potential blocking behavior, or error handling, leaving some behavioral aspects undisclosed.
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, well-structured sentence that immediately conveys the verb, target, and method. It is concise with no filler or redundant 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?
For a simple discovery tool with one optional parameter and no output schema, the description is reasonably complete. It includes the key network mechanism (UDP broadcast) and specifies the device type, which helps differentiate it from sibling discovery tools. It does not explain return values, but given the simplicity and lack of output schema, this is not a significant 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?
The input schema describes the timeout parameter with a clear description and default value, achieving 100% schema coverage. The tool description adds no additional parameter semantics, but with full 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 clearly states the verb 'Discover', the resource 'Dark Dragons Astronomy devices', and the method 'via UDP broadcast'. It distinguishes itself from the sibling tool discover_alpaca_devices by specifying the brand/type of devices, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this tool is for discovering Dark Dragons devices on the local network, which implies when to use it. However, it does not explicitly mention alternatives or when not to use it, such as pointing to discover_alpaca_devices for Alpaca devices. Thus it provides a clear context but no exclusions.
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 disclosing behavior. It specifies the returned fields but does not explicitly state that the operation is read-only, error behavior, or authentication requirements. The verb 'Get' implies a non-destructive query, but additional details 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 concise and well-structured: two sentences, front-loaded with the action ('Get the status'), and every word adds value. No 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?
For a simple one-parameter status tool with no output schema, the description adequately covers the return values (pitch, roll, safe position). It could mention units or what 'safe position' means, but this is a minor gap. Given the tool's low complexity, 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 input schema already describes the sole parameter 'ip' as the IP address of the Mount Sensor device, achieving 100% coverage. The description adds no further parameter semantics beyond reinforcing the device type, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the status of a standalone Mount Sensor device and specifies the returned data (pitch, roll, safe position for roof movement). This distinguishes it from siblings like get_mount_sensors, which likely handles multiple sensors, and ties it to roof operation context.
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 a clear use case: before roof movement, to verify the mount is in a safe position. However, it does not explicitly name alternatives or exclusions, such as when to use get_mount_sensors instead. This is clear context but lacks direct comparison to siblings.
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. It clearly states the primary action (beep/flash) and compatibility, but does not mention failure modes, network requirements, or any other side effects. For a simple actuation command this is adequate, though richer disclosure would be better.
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 that front-load the core purpose and follow with a compatibility note. Every word earns its place, with no fluff or repetition.
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 parameter, no output schema). The description covers purpose and applicable device types, which is sufficient for most use cases. It does not describe return values or error handling, but these are not critical for a beep/flash locate action.
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 fully documents the only parameter 'ip' with a clear description, and the tool description adds no additional parameter-level detail. Since schema coverage is 100%, the 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 ('beep/flash') and resource ('Dark Dragons Astronomy device') to state exactly what the tool does. It also distinguishes from siblings by naming compatible device types (DragonLAIR and Mount Sensor), making it clear this is for physical location rather than status or discovery.
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 when you need to physically locate a device and specifies which device families it works with. It does not explicitly name alternative tools or say when not to use it, but the context is clear enough, and there are no misleading exclusions.
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. It discloses a critical behavioral prerequisite (device must be connected) and implies a read-only operation via 'Get the status.' It also lists example fields, giving insight into what is returned. It does not detail error behavior or permissions, but for a status tool the connection note is significant.
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 long, with the primary purpose stated first and the prerequisite note second. Every sentence adds value, and there is no redundant 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?
For a straightforward status tool with no output schema, the description is complete: it names the device type, gives example status fields, and notes the necessary connection prerequisite. It does not describe the response format, but that is not essential given the tool's simplicity and the schema's completeness.
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 has 100% coverage with descriptions for all parameters (ip, port, device_number). The description adds no additional parameter information, but since the schema is comprehensive, 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 states the tool's function: 'Get the status of an ASCOM Alpaca camera including temperature, cooler state, and exposure status.' The verb 'Get' and resource 'ASCOM Alpaca camera' are specific, and listing example fields distinguishes it from sibling status tools for other devices.
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 for when to use the tool (checking camera status) and includes a key prerequisite: 'Device must be connected first using alpaca_device_connect.' It does not explicitly mention alternatives or exclusions, but the specific device focus implies separation from other alpaca status 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?
With no annotations provided, the description carries the full burden. It explicitly notes the connection requirement, which is a key behavioral prerequisite. The verb 'Get' also implies a read-only operation with no side effects, though it does not elaborate on error behavior or return format.
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 long, with the core function stated first and a necessary note second. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status retrieval tool, the description covers the essential purpose and a critical prerequisite. The output format is not described, but the type of data ('observing conditions') is implied by the purpose. Given no output schema, this is adequate but could be slightly more detailed about return content.
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?
All three parameters (ip, port, device_number) have descriptions in the input schema, covering 100% of the parameters. The tool description adds no additional parameter-specific guidance, so it meets the baseline for high schema coverage but does not exceed 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 clearly states the tool's function: 'Get the current observing conditions from an ASCOM Alpaca weather station.' It uses a specific verb (Get), identifies the resource (observing conditions), and specifies the domain (ASCOM Alpaca weather station), which distinguishes it from sibling status tools for other devices.
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 a clear prerequisite note: 'Device must be connected first using alpaca_device_connect.' This gives context for when the tool can be used. However, it does not directly mention alternatives or when not to use it, so it falls short of a 5.
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 discloses the key behavioral trait: discovery via UDP broadcast. It also states that it returns a list of equipment types. However, it does not mention potential failure modes, timeout behavior beyond the schema default, or any network requirements, which would further enhance transparency given no annotations are provided.
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 concise, front-loaded sentence conveys the tool's purpose, method, and expected result. Every part adds value, and there is no redundant or vague wording.
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 discovery tool with one optional parameter and no output schema, the description is mostly complete: it states the discovery mechanism and the categories of returned devices. A minor gap is not describing the return structure (e.g., whether it returns IP addresses or device IDs), but the included device type list helps the agent understand the output scope.
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, timeout, is already fully described in the schema as 'Discovery timeout in milliseconds (default: 5000).' The description itself adds no additional meaning to the parameter, so the baseline of 3 applies due to full schema coverage.
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 'Discover' and identifies the resource as 'ASCOM Alpaca devices on the local network via UDP broadcast.' It clearly scopes the tool to Alpaca-compatible equipment and lists example device types, distinguishing it from more generic discovery tools like discover_devices.
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 when to use this tool: when needing to find Alpaca-compatible astronomy equipment on the local network via UDP. It provides clear context but does not explicitly state when not to use it or mention alternatives such as discover_devices or locate_device.
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:

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

Score Badge

Copy to your README.md:

[![dda-mcp-server MCP server](https://glama.ai/mcp/servers/darkdragonsastro/dda-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/darkdragonsastro/dda-mcp-server)

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/darkdragonsastro/dda-mcp-server'

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