Run SELECT queries against an Oracle database to retrieve data, with an optional max_rows limit (default 100).
Execute SELECT queries to read data from the oracle database
Args:
query (string): The SELECT query to execute
max_rows (int, optional): Maximum number of rows to return. Default is 100
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| max_rows | No |
Changes observed during successful MCP inspections.
v0.0.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses that the tool is for SELECT-only reading and that max_rows defaults to 100, but it omits permissions requirements, read-only enforcement details, transaction behavior, and error handling.
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 front-loaded with the core action and then uses a compact Args section for parameters. It is appropriately sized and has no filler, though the Args block slightly duplicates the schema structure.
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 tool has no annotations, no output schema, and 0% schema description coverage, so the description must be complete enough on its own. It leaves return format, SQL dialect, read-only enforcement, permissions, and error behavior unspecified, which is a significant gap for a database query tool.
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, and it does document both parameters: query as the SELECT query to execute and max_rows as an optional row limit with default 100. The semantics are shallow, however, with no SQL dialect, format, or constraint details beyond what the schema already implies.
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 a specific verb (Execute) and resource (SELECT queries against the oracle database), and the word SELECT implicitly distinguishes it from siblings like exec_dml_sql and exec_ddl_sql. It stops short of naming alternatives explicitly, so it is clear but lacks full sibling differentiation.
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?
Usage is implied by the phrase 'Execute SELECT queries to read data', which tells an agent this is for read-only querying. However, there is no explicit when-to-use guidance, no exclusions, and no mention of sibling tools such as get_top_queries or explain_query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.