Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are supplied, so the description carries the full behavioral burden. It does convey the read-only nature of '查看' and that output covers columns, types, defaults, and comments, plus the database scope. It omits any mention of permissions, prerequisites, or behavior when the table does not exist — gaps for a zero-annotation tool, but the operation is inherently low-risk.

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 main sentence is front-loaded and states the returned fields immediately. The trailing 'Args:' block largely restates the single schema property, adding little, but the total length is small and not padded.

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?

An output schema exists, so the description needn't enumerate return values, and it still names the key fields it exposes. For a single-parameter read tool this is close to sufficient; the missing piece is guidance on precedence relative to the sibling query/list tools.

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 add meaning beyond the bare 'Table Name' title by stating the parameter is a table name accessible within Archery, implying it should come from the accessible-table namespace. It stops short of specifying qualification (schema.table) or format constraints.

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 and resource ('查看...指定表的字段、类型、默认值和注释' — view a specified table's columns, types, defaults, and comments) and scopes it to 'the currently configured target database'. This clearly separates it from list_tables, which enumerates tables rather than describing one, though the description never names the sibling explicitly.

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?

There is no statement of when to use this tool versus list_tables, query, sql_check, or query_history. The agent must infer that this is a schema-inspection step, but nothing in the text confirms that or rules out alternatives.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden; it discloses the case-insensitive matching behavior, which is genuinely useful. However, it does not state that this is a non-mutating read, nor anything about result size, pagination, or behavior when the target database is unset.

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 entry is short and front-loaded, with the purpose stated before the argument notes. The Args block is slightly redundant formatting for a single parameter but wastes little space.

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?

An output schema exists, so return values need no explanation, and the sole parameter is documented. The scope (current target database) is stated; only edge-case behavior on empty or missing configuration is unaddressed.

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% and the single 'keyword' parameter is undocumented in the schema, so the description must compensate. It does: the keyword is described as optional and case-insensitive, fully covering the only 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 gives a specific verb and resource: it lists tables in the currently configured Archery target database, with optional name filtering. This is clear enough to distinguish it from siblings like describe_table or query, though it never explicitly contrasts itself with them.

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?

There is no guidance on when to call this versus the siblings (describe_table, query, query_history, sql_check). The filtering capability is described, but no context or prerequisites for using this tool are offered.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does substantial work: it discloses that executability, read-only status, sensitive-field detection, row caps, timeouts, and result masking are all governed by Archery's permissions/policies, and that this MCP neither rewrites SQL nor masks returned fields. That is exactly the kind of governance and side-effect context an agent needs.

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?

Purpose is front-loaded in sentence one, behavior in the middle, parameters last. Slightly verbose but every sentence adds decision-relevant information; no filler.

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?

An output schema exists, so return values need not be described. Given that, the description covers purpose, policy-driven behavior, and both parameters well; only explicit sibling routing is missing.

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: sql is defined as the query to submit, and limit's fallback chain is explained (ARCHERY_QUERY_LIMIT when omitted, 0 defers to Archery's maximum permission limit) — semantics the bare integer schema cannot convey.

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 first sentence states a specific verb+resource: executing SQL queries through Archery. It is clearly distinguishable from siblings like list_tables, describe_table, and query_history, though it never explicitly names those alternatives to sharpen the boundary.

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 context is implied — this is the tool that submits SQL to Archery while sql_check and query_history serve other roles — but there is no explicit when-to-use/when-not-to-use guidance, nor any instruction to run sql_check first or a statement of prerequisites.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry behavioral disclosure. '查看' implies a read-only operation and the scope is limited to the current account's own history, but it does not mention permissions, authentication requirements, rate limits, or pagination behavior. The output schema exists, so return format need not be described.

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 purpose and then lists the two parameters efficiently. There is no redundant or filler text, and the argument structure is easy to parse.

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?

For a simple two-parameter read/list tool with an output schema, the description covers the purpose and both parameters sufficiently. It could be stronger with explicit usage routing against siblings or a note on permissions, but nothing critical for invocation is missing.

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 does: limit is described as the number of returned records and must be a positive integer, while search is described as filtering by SQL content, username, or alias. Both parameters gain meaning beyond the bare schema.

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 and resource: viewing the current Archery account's own online query history. It clearly separates this from query execution siblings like query and sql_check, but does not explicitly name or compare against those alternatives.

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 intended use is implied: retrieve the current account's query history. However, there is no explicit guidance on when to use this instead of query, sql_check, or other siblings, nor any when-not conditions.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden and does well: it discloses that the Archery platform API is called, that the account must be whitelisted with deployment permission, and that when the platform is unavailable local results are retained with an explanation. What it does not disclose is how violations are reported or whether the check itself fails hard, 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in sentence one, the rule list is compact and scannable, and the Args section is separated cleanly. Every bullet carries information, though the formatting is denser than strictly necessary for a single-parameter tool.

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?

For a tool of this complexity (local rule engine plus external platform dependency) the description covers scope, the external auth precondition, and degradation behavior, and an output schema exists so return values need not be explained. Only the failure/reporting semantics remain unstated, a minor gap.

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: 'sql: 待检查的上线 SQL，可包含多条语句（分号分隔）' tells the agent the value is deployment SQL and that multiple semicolon-separated statements are accepted. That is real semantic value (delimiter convention, multi-statement support) beyond the bare 'string' in the schema.

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 opening line names a specific verb and resource ('检查上线 SQL' against built-in rules and Archery platform requirements), which is far more than a restatement of the name. It implicitly separates itself from the query-oriented siblings by stating that SELECT is not accepted. It never names those siblings to route the agent explicitly, so it stops short of a 5.

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 enumeration of what is checked implies this is a pre-deployment validation step, but the description never states when to call it (e.g., before executing DDL/DML) or which sibling to use instead for SELECT queries. Usage is inferable from context rather than explicit, so it lands at minimum-viable.

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