execute_sparql

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 two behavioral traits: automatic PREFIX addition and non-support of string functions in FILTER (only URI comparisons allowed). However, it does not state whether the tool is read-only, what SPARQL query types are allowed, or any auth/rate-limit implications, leaving significant safety behavior undisclosed.

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 concise and front-loaded, stating the core purpose in the first clause and adding a crucial limitation as a clearly marked caution. Every sentence earns its place, with no redundancy or irrelevant details.

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?

The description covers the core function and a significant limitation, and the output schema documents return values. However, for a tool that executes raw SPARQL, it lacks essential context: whether the endpoint supports only SELECT or also updates, whether mutations are allowed, and any safety constraints. This gap is notable given the tool's power and absence of annotations.

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 explains that PREFIX is auto-added, which relates to the include_prefixes parameter and its default true, offering some semantic value. However, it does not explain that setting include_prefixes=false disables this behavior, nor does it elaborate on the query parameter syntax beyond general SPARQL.

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's function: 'SPARQL 쿼리를 직접 실행합니다' (executes SPARQL queries directly). The term '직접' (directly) differentiates it from the sibling law-specific search tools, making its purpose as a low-level query execution tool unambiguous.

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 implies use cases (direct SPARQL execution) but provides no explicit guidance on when to choose this over sibling tools like search_law. No alternative tools are mentioned or excluded, leaving the agent to infer the niche from context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.