lucky_query_logsQuery centralized logs by passing search, limit, and location fields in a native query object to retrieve matching log entries.
Query centralized logs. Pass Lucky's native query object; common fields are search, limit, and location.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| search | No |
Changes observed during successful MCP inspections.
v0.1.3Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description need not repeat that. However, it adds no behavioral context such as return format, pagination, or sorting. The only extra is 'common fields are search, limit, and location,' which is more about parameters than behavior and is partially inaccurate since 'location' is not in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The purpose is front-loaded. However, the second sentence introduces a potentially misleading field ('location') and does not add enough value to justify its imprecision.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should explain what the tool returns (e.g., log entries). It does not. It also fails to describe the query object schema or clarify how the optional parameters interact. For a tool that accepts a complex nested query object, this is a significant gap, especially given the 0% schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. It mentions 'search, limit, and location' but the schema has 'limit', 'query', and 'search' as top-level fields; 'location' is absent, creating confusion. It also says to pass 'Lucky's native query object' but doesn't explain its structure or how it relates to the separate 'search' and 'limit' parameters. This is insufficient for a nested object parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Query' and the resource 'centralized logs', which is clear and distinct from the specific log tools among siblings (e.g., lucky_cron_logs, lucky_ftp_logs). It is not a tautology, but it lacks explicit differentiation from other log-related tools beyond the word 'centralized'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 sibling log-specific tools. It does not mention that for specific log types (cron, FTP, etc.) one should use those dedicated tools. The description only gives a hint about parameters, not usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.