Execute read-only SQL queries to fetch evidence from Hacker News and arXiv data, returning results as table-formatted strings. Live mode queries the refreshed live store.
読み取り専用 SQL を実行し結果を表形式文字列で返す（＝根拠 SQL）。
live=True で refresh_data 後の最新データ(live ストア)に対して実行する。
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | ||
| live | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior; it does state the tool is read-only and returns a table-formatted string, and it explains the live parameter's effect. Yet it omits details on error handling, permissions, or any constraints beyond read-only, which is a notable gap for a SQL execution tool.
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?
The description is two concise sentences with no waste, front-loading the core purpose and then the live condition. Every sentence contributes essential information.
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?
Given the tool's complexity (SQL execution), the description covers the main behavior (read-only, return format, live store option) but lacks details on output schema specifics, potential errors, or usage limits. While an output schema exists and may mitigate some gaps, the description alone is not fully comprehensive for an agent to handle all edge cases.
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 must compensate. It clarifies the live parameter (using the live store after refresh_data) but offers no additional detail for the sql parameter beyond the tool's read-only nature, leaving its syntax, allowed statements, or limitations undocumented.
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 clearly states the tool executes read-only SQL and returns a table-formatted string, using a specific verb ('実行する') and resource. It distinguishes itself from siblings by emphasizing the read-only nature, which separates it from get_schema, search_text, and refresh_data.
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?
The description provides context for the live parameter, explaining that live=True operates on the latest data after refresh_data, which is a useful condition. However, it does not explicitly state when to choose this tool over siblings or provide exclusionary guidance, leaving the selection criteria implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.