Server Quality Checklist

Tool Scores

• describe_schemaB
  3.1/5.0
  Behavior1/5

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

  The description mentions a 'refresh=true' parameter, but the input schema has no parameters defined. This contradicts the schema, misleading the agent about available options. Additionally, no annotations are provided to clarify behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  Extremely concise—two sentences convey purpose, caching, and usage tip with no wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  No output schema is provided, and the description does not explain the return format or structure of the schema data. While it lists what is included, this is insufficient for a tool with no output schema and no annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% (no parameters), so baseline is 3. However, the description invokes a non-existent parameter ('refresh=true'), adding confusion instead of value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly states the tool discovers the full database schema and enumerates its components (tables, columns, types, primary keys, foreign keys, indexes). Differentiates itself from siblings like 'analyze_table' or 'query_sql' which are more about querying or analyzing specific data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides guidance on caching behavior (results cached 1 hour) and suggests using 'refresh=true' after schema changes. However, it does not explicitly state when not to use this tool or compare it to alternatives among the many siblings, leaving some ambiguity.

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

• saved_queriesB
  3.2/5.0
  Behavior3/5

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

  The description lists four actions with brief behaviors (store, execute, return, remove), but no annotations exist to cover safety or side effects. It lacks details on persistence, authentication, error handling, or what happens when a query is run (e.g., result format). Basic actions are described but not deeply.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

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

  The description is very concise, with two sentences covering the overall purpose and detailed actions. It avoids unnecessary words. However, the inclusion of '[BUILD tier]' adds minor context but slightly disrupts flow. A more structured format (e.g., bullet points) could improve readability.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given zero parameters and no output schema, the description must compensate, but it fails to specify how to indicate the desired action (missing parameter). It also doesn't describe the return format for 'list' or 'run' actions. The tool is incomplete for reliable invocation by an AI agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema is empty, yet the description implies there should be an 'action' parameter to specify what operation to perform. This creates a contradiction: the agent cannot know how to pass the action. The description adds meaning beyond the schema but does so inconsistently, leading to confusion.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: managing a personal library of reusable SELECT queries. It lists four specific actions (save, run, list, delete), making it easy to understand. It differentiates from sibling tools like 'query_sql' by focusing on personal, reusable queries.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 alternatives such as 'query_sql' or 'analyze_table'. The description does not mention prerequisites, context, or situations where this tool is preferred. The '[BUILD tier]' hint is vague and insufficient.

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

• find_n_plus_oneB
  3.3/5.0
  Behavior2/5

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

  Lacks annotations, so description must cover behavioral traits. Only states it fingerprints and flags patterns, but no details on what flags look like, side effects, rate limits, or scope of 'recent query history'. Insufficient for an agent to anticipate behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

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

  Two sentences, front-loaded with primary action. Efficient but could benefit from slight expansion on usage context without becoming verbose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema, no annotations, and no parameters, the description should provide more context about return value, how to interpret results, and how it fits with siblings. Currently incomplete for an agent to use confidently.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  No parameters exist; baseline is 4. The description adds no parameter info, which is acceptable since there are none. Schema coverage is 100% due to empty schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool detects N+1 query patterns from recent query history, using fingerprinting and flagging. It is a specific verb-resource pair that distinguishes from sibling tools like 'explain_query' or 'optimize_query'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance on when to use this tool vs alternatives. Does not mention prerequisites, intended workflow, or when to avoid. The '[ARCHITECT tier]' tag hints at audience but not usage context.

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

• query_firewallB
  3.3/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. It covers key behaviors (blocking, requiring WHERE, logging) but does not detail side effects, persistence, or required permissions. Adequate but not comprehensive for a mutation-like tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

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

  Description is short and to the point, with a bracketed qualifier. It is efficient but not highly structured (one sentence). No wasted words, but could be improved with bullet points or clearer phrasing.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no parameters, output schema, or annotations, the description covers the tool's purpose but lacks details on how rules are specified, what patterns are blocked, or the response format. Leaves some gaps for a new user.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema is empty (0 params, 100% coverage). The description adds meaning by explaining the tool's function, which is sufficient given no parameters to document. It clarifies what the tool does without relying on schema details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool manages per-connection SQL rules with specific capabilities (blocking dangerous patterns, requiring WHERE, logging PII access). It distinguishes from siblings like query_sql or analyze_table. However, 'manage' is somewhat generic, leaving some ambiguity about exact actions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives. The [ARCHITECT tier] hint is present but does not define context or exclusions. Lacks when-not-to-use or mentions of sibling tools like query_sql.

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

• query_historyB
  3.4/5.0
  Behavior2/5

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

  No annotations provided, so description must carry the burden. It does not specify read-only nature, authentication requirements, scope of 'recent', or any side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

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

  Single sentence plus a tag, very concise. The '[BUILD tier]' tag adds minimal value but does not detract significantly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Adequate for a zero-parameter tool, but lacks details on scope (personal vs all users), limits on recency, and whether results are filtered. Output schema not present, so description could be more complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Zero parameters, so baseline is 4. Description adds value by explaining the return data (timing, row counts, status) which is not in the schema (empty).

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns recent queries with specific attributes (timing, row counts, status). It distinguishes itself from sibling tools like query_sql or explain_query.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance on when to use this tool versus alternatives like query_sql or suggest_queries. The '[BUILD tier]' tag is ambiguous and does not clarify usage context.

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

• impact_analysisA
  3.5/5.0
  Behavior2/5

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

  With no annotations provided, the description must convey behavioral traits. It indicates analysis of proposed changes, suggesting read-only behavior, but does not explicitly state whether it modifies data, required permissions, or whether it is safe to run. Lacks details on side effects or risk level.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is a single, front-loaded sentence with a concise list of analysis aspects. Every word serves a purpose; the [ARCHITECT tier] tag adds context. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no parameters and no output schema, the description covers what it does but omits output format or return value. It lists what it analyzes but does not specify how results are presented (e.g., risk score as number, report). Adequate but could be more complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has no parameters, so the description does not need to add parameter info. Baseline is 4 for zero parameters. The description adds no parameter details, which is acceptable.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: analyzing blast radius of schema changes. It lists specific aspects (FK dependencies, affected views, row count, risk score) and distinguishes itself from siblings like analyze_table or describe_schema by focusing on impact analysis of proposed changes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use for schema change impact analysis but does not provide explicit guidance on when to use this tool versus alternatives (e.g., analyze_table, describe_schema). No exclusions or context-specific recommendations are given.

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

• cross_db_queryA
  3.8/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It does not disclose whether the tool is read-only, destructive, or any limitations (e.g., performance impact). The '[ARCHITECT tier]' tag hints at authorization but is not explicit.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is a single sentence plus a tag, efficiently conveying the core functionality with no redundant words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no parameters and no output schema, the description provides adequate coverage of purpose and output. However, it does not explain how the query is specified or any prerequisites, which could be a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With zero parameters and 100% schema description coverage, the description adds value by explaining the return format (unified result set with provenance), which is beyond the schema's scope.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it runs a federated query across multiple connections with different dialects and returns a unified result set with per-source provenance. This is a specific verb-resource combination that distinguishes it from siblings like 'query_sql' which targets single connections.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use for cross-database queries but lacks explicit guidance on when to use this tool versus siblings like 'query_sql' or 'analyze_table'. No exclusions or alternatives are mentioned.

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

• quotaA
  3.8/5.0
  Behavior3/5

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

  Without annotations, the description carries the burden. 'Check' implies a read-only operation, but it does not explicitly state safety, authentication needs, or rate limits. The behavior is partially transparent but could be more explicit.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  A single sentence that is front-loaded with the action and resource. Every word earns its place, and there is no redundancy or unnecessary detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simplicity of the tool (no parameters, no output schema), the description adequately covers the main return fields. It is sufficient for an agent to understand what the tool does and what it returns.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are no parameters, and schema coverage is 100%. The description adds meaning by listing the return values (usage, limit, plan, upgrade options), which is helpful beyond the empty schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Check' and clearly identifies the resource: API usage, daily limit, plan name, and upgrade options. It is easily distinguishable from sibling tools which focus on database operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 alternatives. It does not mention exclusions or context, leaving the agent to infer usage from the title alone.

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

• detect_anomaliesA
  4/5.0
  Behavior3/5

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

  Discloses sampling for tables >100k rows (~5%) and dialect-aware sampling, but does not state if the operation is read-only or any side effects. With no annotations, more behavioral details would be beneficial.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  Two concise sentences with front-loaded purpose and examples, no redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Covers core functionality, output type (severity-ranked alerts), and sampling behavior. Lacks detail on output schema or potential limitations, but sufficient for a no-parameter tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  No parameters defined in schema, so description does not need to add parameter details. Baseline for zero parameters is 4, and description provides adequate context.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states the tool scans a table for unusual patterns like volume drops/spikes, data gaps, etc., distinguishing it from sibling tools like analyze_table or data_profile.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool vs alternatives, though the context of anomaly detection is clear. Could mention when not to use or compare to related tools.

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

• explain_queryA
  4/5.0
  Behavior4/5

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

  With no annotations, the description reveals database-dependent behavior (different EXPLAIN commands) and that it returns plain-English recommendations. It does not state if it modifies data or requires permissions, but the core behavior is well disclosed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  Two sentences with zero wasted words. Key information is front-loaded. The '[BUILD tier]' note adds context without clutter.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given moderate complexity and no output schema, the description adequately covers purpose and output (plain-English recommendations). However, it omits input structure and whether a connection is required, slightly reducing completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has no parameters, leaving the object content ambiguous. The description mentions analyzing a 'SQL query' but fails to clarify how the query is provided or if other fields (e.g., connection) are needed. Baseline for zero params is 4, but this gap reduces the score.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it analyzes a SQL query's execution plan and returns plain-English performance recommendations. It specifies database-specific EXPLAIN commands (Postgres vs MySQL), distinguishing it from sibling tools like 'optimize_query'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for query analysis with mention of database types but lacks explicit when-to-use or when-not-to-use guidance compared to alternatives. No prerequisites or constraints are mentioned.

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

• generate_migrationA
  4/5.0
  Behavior3/5

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

  The description discloses it never executes and outputs dialect-correct SQL, but lacks details on potential side effects, state changes, or permission requirements. With no annotations, the description carries the burden but is partially adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  Two concise sentences, front-loaded with key function, followed by safety and tier note. No extraneous words; every sentence serves a purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no parameters and no output schema, the description covers the main function, safety, and tier. However, it could provide an example or clarify 'plain-English intent' format for better completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema has no properties (0 parameters), so baseline is 4. Description adds no parameter info, but none is needed since there are no parameters to document.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it generates dialect-correct ALTER TABLE migration SQL and rollback from plain-English intent, and explicitly says it never executes. This distinguishes it from sibling tools like query_sql or analyze_table.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not explicitly state when to use this tool vs alternatives, but it implies its purpose for migration generation from plain English, and notes it never executes. No comparison to siblings or exclusion conditions.

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

• optimize_queryA
  4/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. It describes what issues it identifies and that it suggests index DDL, but does not disclose whether it executes queries or requires permissions, leaving behavioral gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  Two concise sentences that front-load purpose and list specific outputs; no wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  No output schema, but description covers return contents (optimized query, explanations, identified issues, index DDL). Could be more explicit about whether the query is actually rewritten or just suggestions.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema has 0 parameters, so baseline is 4. Description adds value by explaining the tool's functionality, though no parameter details are needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states verb 'Suggest' and resource 'optimized version of a SQL query with explanations', and lists specific issues it identifies, distinguishing it from sibling tools like explain_query and suggest_queries.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Description implies usage for query optimization via '[BUILD tier]' but lacks explicit when-to-use or when-not-to-use guidance, and does not mention alternatives among siblings.

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

• show_locksA
  4/5.0
  Behavior3/5

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

  No annotations provided, so description carries burden. It discloses underlying system views per dialect, which is useful behavioral context. However, it does not mention whether the operation is read-only or if it requires special permissions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  Two sentences efficiently convey the tool's purpose and implementation details without unnecessary words. Front-loaded with the core action.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with zero parameters and no output schema, the description is fairly complete: it explains the action and the underlying system views. Could be enhanced by noting dialect support or expected output, but overall sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema is an empty object, so no parameters to document. Description does not explain the return value, but with zero parameters, the baseline is 4. No additional meaning is needed beyond what the schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly states it lists active sessions and blocking locks, specifying dialect-specific system views. Distinguishes from sibling tools as it is the only one focused on locks and sessions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Does not provide explicit guidance on when to use or not use this tool versus alternatives. The description implies usage for lock monitoring but lacks context on alternatives like 'analyze_table' or 'explain_query'.

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

• watch_tableA
  4/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. It explains monitoring and comparison behavior, but lacks details on permissions, side effects, or data retention.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  Two focused sentences plus a tier tag. Front-loads the core purpose efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter tool with no output schema, the description covers the essential functionality. Could mention output format or how to manage the scheduler, but overall adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Zero parameters, baseline 4. Description adds no parameter info since none exist, but it's consistent.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states the tool monitors row count and latest record, comparing to previous snapshot. This distinguishes it from sibling tools like query_sql or analyze_table, as no other tool provides this time-series monitoring functionality.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Implies usage for ongoing monitoring with a built-in scheduler, but does not explicitly state when to use versus alternatives like detect_anomalies or when not to use.

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

• data_profileA
  4.1/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It describes outputs (stats, health score, PII detection, warnings) but does not explain how the table is specified (input schema has no parameters) or any side effects/requirements.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is very concise—two sentences plus a tag—and front-loads the key purpose and trigger phrases. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given siblings like pii_scan and detect_anomalies, the description helps differentiate this as a comprehensive profile tool. However, the empty input schema and lack of output schema leave ambiguity about how to specify the table, reducing completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 0 parameters, so no parameter description is needed. Baseline score of 4 applies as per guidelines.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool produces a 'FULL data quality + compliance report' with specific outputs like per-column stats, health score, and PII detection. It distinguishes from siblings by combining quality and compliance, and explicitly mentions trigger phrases like 'profile' or 'quality report'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit usage guidance: 'Use this when the user says 'profile' or 'quality report' or mentions PII/compliance.' It lacks explicit alternatives or when-not-to-use, but the context is clear and helpful.

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

• generate_seed_dataA
  4.2/5.0
  Behavior3/5

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

  Discloses key behavior ('Never executes') and constraints (respects types, constraints, FK), but does not specify the output format or return value, which is important since no output schema is provided.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  Two concise sentences with no filler; front-loaded with key purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Covers purpose, constraints, and safety ('Never executes'), but lacks explicit mention of what the tool outputs (e.g., returns generated SQL string) given the absence of an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  No parameters; baseline score 4 as schema coverage is 100% and description does not need to add parameter details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly states it generates realistic, schema-aware INSERT statements for development and testing, distinguishing it from sibling tools that analyze, query, or profile data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Identifies usage for development and testing, and explicitly states it never executes, but does not provide when-not-to-use or alternatives.

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

• issue_api_keyA
  4.2/5.0
  Behavior3/5

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

  No annotations provided, but the description includes the rate limit (5 per day) and key format, offering partial behavioral insight. Lacks details on side effects like old key invalidation or permissions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  Three sentences, each earning its place: action, use cases, rate limit. Front-loaded and no unnecessary words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no parameters and no output schema, the description covers key format, use cases, and rate limit adequately. Missing response format details, but tool simplicity allows minor gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema has zero parameters (empty object), so description adds no parameter info. Baseline for 0 params is 4; no additional value needed beyond schema completeness (100%).

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it issues a fresh ta_data_* API key for the current tenant, with specific use cases like pasting into /add-database or configuring integration, distinguishing it from sibling database tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit use cases ('useful for pasting...') and a rate limit, but does not mention when not to use or alternatives, though none are obvious among siblings.

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

• list_connectionsA
  4.2/5.0
  Behavior4/5

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

  Without annotations, the description carries full behavioral burden. It explicitly states that it flags duplicate names and returns nothing sensitive (no DSN, no credentials), which adds valuable safety context beyond the basic listing functionality.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is two sentences with no wasted words. It front-loads the main purpose and covers critical behavioral details efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema, the description explains the return fields and sensitive data exclusion. It avoids the need for output schema documentation. However, it omits potential pagination or limits for large tenant lists, which is minor.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are zero parameters, so the baseline is 4. The description correctly adds no parameter info as none exist, and the schema coverage is 100%.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists every database connection for the tenant and specifies the returned fields (name, id, dbType, createdAt). It distinguishes itself from siblings by mentioning flags for duplicate names and that it returns no sensitive data, which is unique among the sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for viewing connections but does not explicitly state when to use it versus alternatives like test_connection or analyze_table. No guidance on when not to use it is provided, though the tool's simplicity (read-only listing) makes context clear.

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

• pii_scanA
  4.2/5.0
  Behavior4/5

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

  No annotations exist, so description carries burden. It clarifies heuristic nature, non-compliance, and BUILD tier, which adds context beyond basic functionality.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  Two concise sentences front-load the main action and provide key caveats; no wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no parameters or output schema, the description sufficiently explains what it does (scans for PII patterns) and its limitations (heuristic, no guarantee).

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema is empty object (0 params), so baseline is 4. Description implies it operates on all string columns across tables, adding meaning beyond schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool scans string columns for common PII patterns, listing specific examples (email, SSN, etc.), and distinguishes from sibling tools like data_profile or query_sql.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Caveats 'heuristic-only — not a compliance guarantee' are provided, but no explicit guidance on when to use vs alternatives like data_profile or detect_anomalies is given.

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

• query_sqlA
  4.2/5.0
  Behavior3/5

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

  The description notes the tool is read-only and mentions response metadata (connection, dialect). However, it does not explain how to pass the SQL query given the empty input schema, which is a significant behavioral gap. Without annotations, the description should disclose this mechanism.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is brief, front-loaded with the main purpose, and every sentence adds value. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema and no parameters, the description fails to explain how the SQL query is actually provided to the tool (e.g., via a param not in schema, or from conversation context). This is a critical omission for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0 parameters and schema coverage 100%, the description adds value by explaining the tool's constraints and dialect guidance, though it could clarify how the query is supplied.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Execute a read-only SQL query against the target connection.' It specifies permitted keywords (SELECT, WITH, EXPLAIN) and mentions dialect support, making the purpose very clear and distinguishable from siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states when to use this tool (read-only queries) and what is permitted. It provides dialect guidelines and a default LIMIT, giving the agent clear instructions on how to craft the query.

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

• suggest_queriesA
  4.2/5.0
  Behavior3/5

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

  No annotations are present, so the description must carry the full burden. It mentions 'schema-aware' and 'ready-to-run SQL' but lacks details on authentication, rate limits, or whether suggestions are read-only.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  Two concise sentences with no wasted words. Front-loaded with the core action and followed by a use case.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given zero parameters and no output schema, the description is largely complete. However, it omits details on return format or prerequisites like an active connection, which could be inferred from sibling tools.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With no parameters and 100% schema coverage, the description adds value by explaining the tool's purpose and output nature, meeting the baseline for a parameterless tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool generates schema-aware query suggestions with ready-to-run SQL, distinguishing it from siblings like 'query_sql' (execution) and 'explain_query' (explanation).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context ('Great for exploring unfamiliar databases or finding useful queries') but does not explicitly exclude scenarios or mention alternatives like 'query_history' or 'saved_queries'.

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

• test_connectionA
  4.4/5.0
  Behavior4/5

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

  Discloses it performs a SELECT 1 (read-only), returns version and latency, and implies no side effects, though no annotations are provided.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  Two efficient sentences, front-loaded with action and key value, no waste.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Sufficient for a parameterless tool with no output schema, though could explicitly mention connection requirement (likely implicit).

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  No parameters exist, so schema coverage is 100% and the baseline is 4; description adds nothing extra but none needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly states the tool pings a connection, returns server version and latency, and distinguishes from siblings by noting it's faster than describe_schema.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit usage as a fast credential/network check and contrasts with describe_schema, but could also mention alternatives like list_connections.

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

• analyze_tableA
  4.7/5.0
  Behavior4/5

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

  No annotations are present, so the description carries the burden. It implies read-only behavior via 'quick statistical snapshot' and scoping to one table, but doesn't explicitly state whether the tool modifies data or requires specific permissions. The description adequately conveys the non-destructive nature and scope.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is two sentences: the first states the core functionality with specific details, the second provides an alternative. It is front-loaded with 'QUICK statistical snapshot' and contains no superfluous words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema and no annotations, the description covers the main purpose, scope (one table), and available statistics. However, it does not mention output format or any prerequisites. It is adequately complete for a quick statistical tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema is empty (no parameters), so schema coverage is 100%. The description adds value by detailing what the tool analyzes (row count, null rates, etc.), which is not in the schema. This fully compensates for the lack of parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides a 'QUICK statistical snapshot for ONE table' listing specific stats (row count, null rates, cardinality, numeric min/max/avg, date ranges). It also distinguishes itself from the sibling 'data_profile' by noting the alternative is for a 'FULL quality report including PII detection'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says 'Use `data_profile` when the user wants a FULL quality report including PII detection,' providing clear guidance on when to use this tool vs. an alternative.

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