SAP HANA MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.1
Disambiguation4/5
Most tools are clearly distinct by resource (tables, views, indexes, procedures, etc.) and action (list, describe, search). Minor overlap exists between list_constraints and list_foreign_keys, and describe_table vs explain_table, but descriptions clarify the differences.
Naming Consistency5/5
All tool names follow a consistent hana_verb_noun pattern using snake_case. Verbs like list, describe, get, search, and execute are used systematically across resource types.
Tool Count2/5
At 44 tools, the server is quite large, exceeding the 'heavy' threshold of 25. While each tool has a narrow purpose, the sheer number may overwhelm an agent, though the broad SAP HANA scope partially justifies the count.
Completeness5/5
The tool set covers a comprehensive range of HANA metadata exploration, querying, performance monitoring, and even knowledge base management. Read-only operations for tables, views, indexes, constraints, procedures, functions, sequences, privileges, and dependencies are all present, leaving few obvious gaps.
Average 4/5 across 44 of 44 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 19 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no additional behavioral context beyond the literal statement 'Test connection', such as what the test entails, potential side effects, or what a successful/failed result looks like. It is consistent with annotations but contributes no extra transparency.
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 concise sentence that conveys the essential purpose without any redundant or extraneous text. It is perfectly sized for the tool's simplicity.
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?
The tool is very simple (no parameters, no output schema, annotations are present), so the description is minimally adequate. However, it does not explain what the result of the test will be (e.g., success/failure, connection details) or how this differs from similar diagnostic tools like hana_health_check, leaving some context incomplete.
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 zero parameters, and schema description coverage is 100%. The baseline for 0-parameter tools is 4, and since there are no parameters to document, the description has no additional parameter semantics to provide.
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 'Test connection to HANA database' clearly states the tool's verb ('test') and resource ('connection to HANA database'). It is specific enough to convey its purpose, though it does not explicitly distinguish it from similar sibling tools like hana_health_check or hana_get_session_info.
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 provides no guidance on when to use this tool versus alternatives. It does not mention typical use cases, prerequisites, or exclusions, leaving the agent to infer when a connection test is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool's safety profile is well covered. However, the description adds no behavioral context beyond that, such as what 'structure' includes (columns, data types, constraints) or whether it requires schema_name for ambiguous names, so it doesn't go beyond the annotations.
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, compact sentence that conveys the core function without any wasted words. It is front-loaded with the verb and resource, making it easy to scan.
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 straightforward metadata query tool, the description is minimally adequate but leaves open questions about return format and edge cases (e.g., table not found, schema ambiguity). Given the rich sibling set and no output schema, more detail about what 'structure' means and when schema_name is required would improve 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 already provides detailed descriptions for all three parameters, including the purpose of catalog_database and its override behavior. The tool description adds no additional information about parameters, so with 100% schema coverage, a baseline score of 3 is appropriate.
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 action (describe) and resource (table structure of a specific table), making the tool's function unambiguous. However, it does not explicitly distinguish this from sibling tools like hana_explain_table or hana_get_table_stats, so it earns a 4 rather than a 5.
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 provides no guidance on when to use this tool over alternatives, such as hana_explain_table or hana_list_tables. It simply states the function with no context, preferred use cases, or exclusions, so the agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation Contradiction: readOnlyHint=true and idempotentHint=true conflict with the stated optional action 'append the result to a CSV history file'. Appending is a write operation and repeated invocations with save_history=true would create duplicate history rows, violating idempotency. The description discloses a side effect that contradicts the annotations.
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, well-formed sentence with no wasted words. It front-loads the core purpose and then clarifies the optional parameter behavior, making it highly concise and easy to parse.
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?
There is no output schema, and the description does not specify the snapshot's contents or return format. However, the tool has only two optional parameters and a straightforward monitoring purpose, so the description is minimally adequate but leaves room for ambiguity around outputs.
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?
Input schema has 100% coverage with clear descriptions for output_file and save_history, so the schema already documents parameters. The description adds little beyond reinforcing the CSV append behavior, aligning with the baseline for high schema coverage.
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 uses a specific verb ('Take a memory snapshot') with a concrete resource ('HANA indexserver') and defines the comparison scope ('compare usage against allocation limits'). This clearly distinguishes it from sibling monitoring/performance 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 when to use the tool (memory snapshot monitoring) and mentions the optional CSV history feature, but it does not explicitly state when to choose this tool over alternatives or any exclusions. Overall context is clear but directional guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read-only nature is known. The description adds no extra behavioral context (e.g., what 'structure' includes, whether it lists columns, or any system table dependencies), but it does not contradict the annotations.
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 seven-word sentence that is front-loaded with the primary action and object. It is perfectly concise with no wasted words or redundant information.
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?
With no output schema, the description does not explain what the returned 'structure' includes or how to interpret it. It also fails to mention optional parameters' roles or any usage context beyond a minimal statement. Given the tool has 4 parameters and siblings that describe other objects, the description is insufficiently complete for an agent to fully understand the tool's behavior.
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 100% coverage with descriptions for all parameters, including optional ones like schema_name and catalog_database. The tool description adds no additional parameter meaning beyond the schema, so a baseline score of 3 is appropriate.
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 'Describe the structure of a specific index' clearly identifies the action (describe) and the resource (index), with the qualifier 'specific' distinguishing it from listing all indexes or describing tables. It is a concise, unambiguous purpose statement.
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 provides no guidance on when to use this tool versus alternatives like hana_list_indexes or hana_describe_table. It neither states the typical use case nor mentions any exclusions or complementary tools, leaving the agent without decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's simple 'Show' aligns with the safety profile. The description adds no extra behavioral context, but none is needed beyond confirming a non-destructive read operation.
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 one short sentence with no wasted words. It is front-loaded and appropriately concise for a tool with no parameters.
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?
The tool has no output schema and minimal description, so it's unclear what 'configuration' includes or what the response format is. For a simple read-only config tool, this may be acceptable, but the description could clarify whether it returns file contents, runtime settings, or a summary.
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 tool has zero parameters, so the schema fully covers semantics. Per rubric, baseline for 0 params is 4; the description is not required to add parameter details since none exist.
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 shows the HANA database configuration, using a specific verb and resource. However, it doesn't distinguish between the many 'show' siblings like show_env_vars or show_license_info, so it's clear but not fully differentiated.
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 given on when to use this tool versus alternatives. With a large sibling list containing other 'show' and 'get' tools, the description provides no context for selection or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds context about pagination with HANA_LIST_DEFAULT_LIMIT and offset, but does not disclose ordering, whether system tables are included, or other behavioral traits. It provides moderate value beyond annotations.
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, focused sentence that gets to the point. It front-loads the main function and includes optional modifiers without excess.
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 simple list tool with full schema and output schema, the description is adequate but lacks context about optional schema_name behavior or how it differs from hana_search_tables. The catalog_database parameter is not explained in the description, though the schema covers it. It is a minimum viable description.
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 provides descriptions for all 5 parameters, so coverage is 100%. The description adds only a reference to HANA_LIST_DEFAULT_LIMIT for pagination, which is a minor addition. Since the schema already explains the parameters, the description does not significantly enhance semantics.
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 lists tables in a schema, with optional prefix and pagination. It is specific about the action (list) and resource (tables), but it does not differentiate from sibling tools like hana_search_tables, stopping 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for enumerating tables in a schema but gives no explicit when-to-use or when-not-to-use guidance relative to alternatives. It mentions optional prefix and pagination but no exclusions or prerequisites. The sibling set includes hana_search_tables and hana_list_schemas, so more guidance would be useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that results come from SYS.PROCEDURES and include parameter counts, which is useful, but it does not disclose additional behavior such as pagination defaults, schema name fallback, or ordering.
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 concise sentence that directly states the tool's purpose and result content. There is no redundant or extraneous 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?
Given the simple read-only nature, the annotations, and a schema with four optional parameters, the description is largely sufficient. It specifies the source (SYS.PROCEDURES) and the returned information (parameter counts), but could marginally mention defaults or return shape, especially since no output schema is provided.
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 schema description coverage is 50%, with limit and offset lacking descriptions. The tool description does not provide any additional meaning for these parameters, nor does it explain the default for schema_name. Thus, it fails to compensate for the schema's incomplete parameter documentation.
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 stored procedures and their parameter counts from SYS.PROCEDURES. The verb 'List' and resource 'stored procedures' are specific, and this distinguishes it from sibling tools like hana_list_tables or hana_list_functions.
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 usage is implied by the title and description: it is a listing tool for stored procedures. However, it does not explicitly state when to use it over alternatives like hana_describe_procedure or hana_list_functions, nor does it mention any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating operation (readOnlyHint=false). The description adds a useful non-destructive promise ('Preserves local KB cases and configuration'), but it does not disclose other potential side effects such as service restarts or failure modes. The additional context is modest.
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 action front-loaded. No filler or redundant phrasing.
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 simple tool with one parameter and no output schema, the description covers core behavior and one key preservation guarantee. It might benefit from noting that confirmation is required, but that is already in the schema, so the description is adequate.
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?
Schema description coverage is 100% for the single confirm parameter, which the schema already explains. The description does not add any extra meaning about the parameter or its required true 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?
The description clearly states a specific action ('Download and install the latest HANA MCP client update') with a clear resource. It distinguishes itself from sibling hana_check_for_updates by focusing on applying the update rather than checking for it.
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 provides context that it installs the latest update and preserves KB/config, but it does not explicitly say when to use it versus alternatives like hana_check_for_updates. No when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation as read-only and idempotent. The description adds that it queries system views SYS.VIEWS and SYS.VIEW_COLUMNS, which provides some context about the data source. However, it does not disclose potential permission requirements or limitations, which would add further transparency.
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, focused sentence that directly conveys the tool's function without any redundant information. It is front-loaded and appropriately concise.
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 tool's simplicity, good annotations, and full schema coverage, the description is reasonably complete. It mentions both the SQL definition and column metadata, covering the expected output. However, there is no output schema, and the description does not specify the exact return structure, which leaves a small gap.
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?
Schema description coverage is 100%, so the parameters are already fully documented. The description does not add additional meaning or context beyond the schema. It describes the overall purpose without detailing parameter-specific behavior or usage.
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 the view definition (SQL) and column metadata, specifically from SYS.VIEWS and SYS.VIEW_COLUMNS. This distinguishes it from sibling tools like hana_describe_table or hana_describe_procedure, making the purpose unambiguous.
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 versus alternatives, nor does it mention exclusions. However, the tool name and title imply usage for describing a view, so the context is indirectly clear. No alternative tools are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation safe (readOnlyHint, idempotentHint, destructiveHint false). The description adds the source catalog views and the constraint types returned, but does not elaborate on behavior such as ordering, pagination, or error handling. It does not contradict the annotations.
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 that directly states the tool's function. It includes useful implementation detail in parentheses without any redundant or filler content.
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 simple read-only metadata list tool with well-documented parameters and safe annotations, the description is sufficiently complete for an agent to invoke it correctly. It states what types of constraints are returned and the source system views, though it does not describe the exact output columns, which is a minor gap given no output schema.
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 already provides complete descriptions for all three parameters (table_name, schema_name, catalog_database), including default behavior. The tool description does not add further explanation of parameter semantics, so it stays at the baseline for 100% schema coverage.
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 a specific action ('List') and a specific resource ('primary key, unique, check, and foreign key constraints for a table'). It also identifies the underlying system views, making the tool's scope unambiguous and distinguishing it from sibling tools like hana_list_foreign_keys.
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: call this when you need constraint information for a table. However, it provides no explicit guidance about when to prefer this over alternatives (e.g., hana_list_foreign_keys) or any exclusions, so usage guidance remains only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds meaningful context by specifying the source system view (SYS.REFERENTIAL_CONSTRAINTS) and the output content (column, referenced table/column, delete rule), which is useful beyond the annotations.
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, well-structured sentence that is front-loaded with the action and resource, and it includes essential output details without any unnecessary words or repetition.
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?
While there is no output schema, the description lists the key output fields (column, referenced table/column, delete rule). Combined with the complete input schema and clear annotations, the description is mostly complete for a simple read-only listing tool, though it could briefly note that results are empty if no FKs exist.
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 100% description coverage for all three parameters, including schema_name default and catalog_database purpose. The description does not add additional parameter semantics beyond what the schema already provides, so a baseline score of 3 is appropriate.
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 lists referential constraints (foreign keys) with column, referenced table/column, and delete rule, sourced from SYS.REFERENTIAL_CONSTRAINTS. This is specific and actionable, but it does not explicitly differentiate from the sibling tool hana_list_constraints, which may cover a broader scope.
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 intended use is implied: to list foreign keys on a table. However, there is no explicit guidance on when to use this tool versus alternatives like hana_list_constraints or hana_describe_table, nor any mention of prerequisites or schema defaults beyond what the input schema provides.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful context about the source table (SYS.FUNCTIONS) and that both scalar and table functions are listed, but it does not disclose details like default limits or pagination behavior, which would enhance transparency.
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 long, front-loads the primary purpose, and packs essential details like source view and supported features without redundancy. Every word contributes to understanding, making it highly concise and well-structured.
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 simple list operation with strong annotations, the description provides adequate context: what is listed, from where, and key capabilities. It lacks an explicit mention of the schema_name default (HANA_SCHEMA) or return format, but those are partially covered by the schema and the simplicity of the tool. No output schema exists, but the description is still fairly complete for its scope.
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?
Schema description coverage is 50%, with limit and offset lacking descriptions. The description mentions 'pagination' and 'prefix filter', which hints at the purpose of limit/offset and prefix parameters, but it does not explain default values or how these parameters interact. This adds some value but does not fully compensate for the schema gaps.
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 'List scalar and table functions from SYS.FUNCTIONS', specifying both the action and the resource. It distinguishes this from sibling tools like hana_list_procedures by specifying function types and the source system view. The support for prefix filter and pagination further clarifies its 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?
The description implies when to use the tool (to list functions) and mentions capabilities like prefix filtering and pagination, but it does not provide explicit exclusions or contrast with alternatives such as hana_describe_function or hana_list_procedures. Usage context is clear but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior. The description adds the scoping phrase 'for a specific table,' which is useful, but it does not elaborate on return format, pagination, or the effect of the optional catalog_database parameter. This is consistent with annotations, so no contradiction.
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, front-loaded with the verb 'List' and the resource. It is succinct and contains no filler or redundant phrases.
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 low complexity, full schema coverage, and helpful annotations, the description is nearly complete. It lacks explicit mention of return values, but for a simple list operation reading indexes, this is not a significant gap. The absence of an output schema is not a concern here.
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 schema covers all three parameters with descriptions (100% coverage). The tool description does not add semantic value beyond the schema; it only repeats the notion of a specific table, which is already evident from the table_name parameter.
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 action (list) and resource (indexes for a specific table), with a specific scope. It distinguishes itself from sibling tools like hana_describe_index or hana_list_tables by focusing on index enumeration.
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 this tool is for retrieving indexes for a given table, but it does not explicitly contrast with alternatives like hana_describe_index or state when not to use it. No exclusionary or alternative-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose read-only, idempotent, and non-destructive behavior. The description adds value by specifying the data source (SYS.SYNONYMS) and the returned attributes, which provides useful context without contradicting annotations.
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, efficient sentence that conveys the essential purpose and output without any fluff. It is well-structured and easy to parse.
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?
Despite the simple nature of a list tool and good annotations, the incomplete parameter documentation and lack of output schema leave gaps. The description is minimally sufficient but does not fully cover pagination behavior or defaults, making it a moderate score.
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 only 50%, with limit and offset lacking descriptions. The description does not compensate for this gap by explaining these parameters or their behavior, so it fails to add meaning beyond the 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's function: listing synonyms in a schema, identified by source (SYS.SYNONYMS) and output fields (target object schema, name, type). It effectively distinguishes itself from sibling tools that list other object types (e.g., tables, views).
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 clear context that this tool is for listing synonyms, implicitly indicating when to use it versus other list tools. However, it does not explicitly state exclusions or mention alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavior about merging external business semantics from file/URL sources and reading SYS.* from another MDC database, giving context beyond the annotations.
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, front-loaded with the action and result. No redundant wording. Each sentence adds meaningful detail about optional behavior or context.
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 moderate complexity, rich schema, and output schema, the description adequately covers the essential aspects. It mentions external config sources and cross-database behavior but doesn't elaborate on error conditions or when business semantics might be absent—minor gaps for a read-only 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?
Schema coverage is 100%, but the description enriches parameter meaning by explaining how catalog_database affects JSON key lookup (DB.SCHEMA.TABLE vs SCHEMA.TABLE) and the role of HANA_SEMANTICS_PATH/URL. This goes beyond the schema descriptions.
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 returns column metadata merged with optional business semantics, which is a specific verb+resource. The unique aspect of business semantics from HANA_SEMANTICS_PATH/URL distinguishes it from sibling describe tools, though it doesn't explicitly name alternatives.
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 explains when optional parameters are relevant (e.g., catalog_database for MDC, semantics path/URL for business metadata), but it doesn't explicitly state when to choose this tool over hana_describe_table or other metadata tools. Usage context is implied rather than clearly differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation as read-only, idempotent, and non-destructive. The description adds context by specifying the system view source and the exact fields returned, which aids in understanding output shape. It does not mention pagination or ordering details, but safety traits are fully covered by annotations.
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, concise sentence that front-loads the action ('List sequences') and includes the key resource and output details. No unnecessary words or repetition.
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 simple nature of a list tool and the presence of annotations, the description provides sufficient information about the tool's purpose and output. It lacks explicit pagination/default behavior, but the parameters limit/offset are self-explanatory and the description covers the core functionality.
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 description coverage is only 50%, with limit and offset lacking any description. The description does not compensate by explaining parameter behavior, such as the default schema_name or how prefix filtering works. It only lists output fields, leaving undefined parameters without guidance.
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 sequences from a specific system view (SYS.SEQUENCES) and enumerates the exact attributes shown (start, min, max, increment, cycle, cache). This distinguishes it from sibling listing tools like list_tables or list_indexes.
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 sequence definitions but provides no explicit guidance on when to use this tool over alternatives. It does not mention exclusions or alternative tools, leaving the agent to infer from the tool name and content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive, covering the safety profile. The description adds value by listing exactly what indicators are included, giving the agent a concrete expectation of the snapshot contents. No contradictions with annotations.
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 one well-structured sentence with a colon and comma-separated list. It is front-loaded with the key phrase 'Live performance indicators' and lists all relevant metrics without unnecessary filler. The length is justified by the number of indicators covered.
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?
Although there is no output schema, the description enumerates the categories of data returned, which gives the agent a clear idea of the snapshot's scope. For a read-only tool with one optional parameter, this is adequate. It could be improved by mentioning the output format, but it is not essential.
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 single parameter schema_name is fully described in the input schema, including its default behavior via HANA_SCHEMA env var. Schema coverage is 100%, so the description does not need to add further parameter details. Baseline of 3 is appropriate.
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 identifies the tool as a live performance snapshot and enumerates the specific metrics it covers (open transactions, top SQL plan cache queries, long connections, column-store delta sizes, blocked transactions). This distinguishes it from siblings like hana_get_expensive_queries and hana_memory_monitor, making the purpose unmistakable.
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 'Realtime performance snapshot' label implies usage for immediate performance overview, but there is no explicit guidance on when to choose this tool over related tools such as hana_get_expensive_queries or hana_health_check. It provides context without exclusions or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the source table (SYS.FUNCTION_PARAMETERS) and what is returned, which is useful context beyond annotations. However, it doesn't disclose edge cases (e.g., behavior if the function doesn't exist) or any permission requirements, so it provides only moderate additional transparency.
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, concise sentence that front-loads the primary action and return content. It contains no filler or redundant information, making it highly efficient.
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?
Even without an output schema, the description explicitly lists the returned fields (parameter names, types, data types, positions), which covers the return-value expectations. Combined with complete annotations and clear schema, the tool is adequately described for its simple purpose. It could mention default schema behavior, but that is covered by the schema definition.
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 100% coverage for all 3 parameters, so the schema already documents each parameter. The description does not add extra meaning beyond the schema; it simply restates that it returns function parameters. Baseline of 3 is appropriate because the schema does the heavy lifting.
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 a specific verb ('Return') and resource ('parameter names, types, data types, and positions for a function') and identifies the source view SYS.FUNCTION_PARAMETERS. It distinguishes itself from sibling describe tools (e.g., hana_describe_table, hana_describe_procedure) by focusing specifically on function parameters.
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 implicitly conveys when to use this tool: when you need function parameter details. It doesn't explicitly mention alternatives or exclusions, but the context is clear given the sibling tools. A 4 is appropriate because there is no confusion about its intended use, though no explicit 'use instead of X' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no safety hints (all false), so the description carries the burden. It reveals that only SELECT/WITH are accepted and that the result is an operator tree from EXPLAIN_PLAN_TABLE, which is useful. However, it does not explicitly state that the tool is read-only, mention required privileges, or describe error behavior, leaving room for more disclosure.
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 long, front-loads the core action, and includes a concise constraint. Every word adds value with no redundancy or fluff, making it highly efficient.
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 tool's simplicity (one parameter, no output schema), the description provides adequate context: what it does, what input is allowed, and what output to expect. It could mention limitations or prerequisites (e.g., whether special permissions are needed), but the current level is sufficient for most use cases.
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?
Schema description coverage is 100%, so the schema already documents the 'query' parameter fully. The description adds no new semantic detail beyond what the schema provides, only restating the SELECT/WITH restriction. Thus, a baseline score of 3 is appropriate.
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 a specific action ('Run EXPLAIN PLAN') on a specific resource (a SELECT/WITH query) and specifies the output ('operator tree from EXPLAIN_PLAN_TABLE'). It also distinguishes from sibling tools like hana_explain_table by focusing on query execution plans rather than table structure.
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 clear context for when to use the tool (to explain a SELECT/WITH query) and an explicit exclusion ('Only SELECT/WITH are accepted'). However, it does not explicitly mention alternatives or contrast with sibling tools, so it falls short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool writes to docs/kb/index.md and requires a license feature, which is behavioral information beyond the empty annotations. However, it does not mention idempotency, potential side effects, or behavior when the file is missing, leaving some transparency 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?
The description is a single, front-loaded sentence that conveys the action, target, source, and prerequisite without unnecessary words. Every element earns its place.
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 parameterless tool, the description adequately covers the core purpose, data source, and license requirement. It does not mention edge cases like missing index files or when to run it, but the simplicity of the tool makes these non-critical 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?
The tool has zero parameters, so the schema is fully covered and the description needs no parameter explanation. The baseline of 4 is appropriate as there is nothing to add.
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 specific action 'regenerate', the target resource 'docs/kb/index.md', and the data source 'saved cases'. It is distinct from sibling tools that read, search, or save knowledge base cases, making the purpose unmistakable.
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 the tool is for rebuilding the index from saved cases but does not explicitly state when to use it versus alternatives like hana_search_knowledge_base or hana_read_kb_case. No exclusion or alternative references are provided, leaving the usage context somewhat implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds useful behavioral context about result shaping with row/column/cell caps, which goes beyond annotations. No contradiction with the annotations.
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 compact sentences with no filler. The first sentence states the core function, and the second adds a relevant constraint about result caps. Every word earns its place.
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?
With an output schema and strong annotations, the description covers the essential behavior. A minor omission is the lack of any note about row ordering (SELECT TOP without ORDER BY), but for a simple sampling tool this is not critical. Overall it is quite complete.
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?
Schema descriptions for all three parameters are complete, covering defaults and maximums. The description adds no additional parameter semantics, so baseline 3 applies due to 100% schema coverage.
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 verb 'Fetch' and the resource 'first N rows from a table', with explicit method 'SELECT TOP'. This distinguishes it from the more general hana_execute_query, making the tool's function unambiguous.
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 prefer this tool over alternatives like hana_execute_query. The reference to 'same caps as hana_execute_query' implies a scoped sampling use case, but the usage context is only implied, not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe-read nature is well covered. The description adds behavioral context beyond annotations by enumerating the diagnostic areas covered (memory metrics, top tables, blocked transactions), which helps the agent set expectations. It does not mention performance impact or required permissions, but the annotation coverage lowers the burden.
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 that clearly states the action and then efficiently lists the key diagnostic components. Every part adds value, with no filler or repetition.
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?
The tool is moderately complex and has no output schema, so the description must convey enough about scope and results. It lists the main diagnostic categories, giving a solid sense of what will be returned, though it stops short of detailing the exact response format. Given the breadth of a health check, this is reasonably complete.
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 100% coverage for the single parameter 'schema_name', fully describing its purpose and default. The tool description adds no additional parameter-level detail, but since the schema already carries complete semantics, baseline 3 is appropriate.
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 states a specific verb+resource: 'Run a read-only diagnostic snapshot against the HANA database.' It lists concrete components (database info, services, memory metrics, top tables, blocked-transaction count), which distinguishes it from sibling tools like hana_memory_monitor or hana_show_config that target narrower areas.
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 broad health checking, but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. No sibling tool is referenced for comparison, leaving the agent to infer context from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the read-only, idempotent, non-destructive nature. The description adds the source table SYS.VIEWS and confirms support for prefix filtering and pagination, but doesn't disclose any unexpected behaviors like default ordering or system view filters. Additional context like result formatting is absent, but the annotations cover the safety profile.
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, front-loaded with the core action, with no redundant information. Every word contributes to understanding the tool's scope and capabilities.
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?
The description, combined with detailed parameter schemas and safety annotations, provides sufficient context for using this straightforward list tool. It doesn't include explicit return structure, but for a simple listing operation the results are intuitive. An explicit alternative note would make it a 5.
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?
Schema description coverage is 100%, so the schema already documents each parameter's purpose and defaults. The description mentions prefix filtering and pagination, which maps to prefix, limit, and offset, but adds no new semantics beyond what's in the 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 explicitly states the tool lists views in a schema from SYS.VIEWS, which clearly distinguishes it from sibling tools like hana_describe_view or hana_list_tables. The verb 'List' and resource 'views' are specific and unambiguous.
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 clearly establishes the tool's purpose for listing views in a schema, which implies when to use it. However, it does not explicitly mention alternatives or exclusions, such as using hana_list_calculation_views for calculation views or hana_describe_view for a single view's details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the tool searches a local Markdown knowledge base and requires a license feature, which is useful operational context. However, it does not describe result format, pagination, or any search behavior details, so the description provides moderate additive value beyond annotations.
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, grammatically concise sentence that front-loads the main action and includes the key prerequisite (license requirement) in a parenthetical. Every word earns its place; there is no fluff or 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?
For a simple search tool with two straightforward parameters, annotations covering safety, and no output schema, the description is sufficient. It names the resource and purpose, and the license prerequisite is noted. It could mention what the results look like (e.g., case titles) but this is not critical given the low complexity and well-understood search semantics.
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 fully describes both parameters: query is 'Search query (required)' and limit is 'Max results to return'. Schema description coverage is 100%, so the baseline for this dimension is 3. The tool description itself does not add any additional semantic detail about the parameters, so it does not exceed the baseline.
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 function: 'Search the local Markdown knowledge base for previous cases'. It uses a specific verb ('search'), identifies the resource ('local Markdown knowledge base'), and the purpose ('previous cases'), distinguishing it from sibling tools like hana_search_tables (which searches tables) and hana_read_kb_case (which reads a specific case).
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 clear context by specifying the tool is for searching the knowledge base and mentions a prerequisite (requires knowledge-base license feature). It implies when to use this tool (when searching for prior cases) but does not explicitly name alternatives or exclusions. This is clear context without explicit alternative guidance, warranting a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, fully covering the tool's safe, read-only nature. The description adds no extra behavioral context beyond the function's name, such as output format, pagination, or edge cases, so it does not go beyond what annotations provide.
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 no filler words. It states the action, scope, and purpose efficiently, making effective use of minimal space.
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 tool's simplicity (0 parameters, no output schema) and the strong annotations, the description provides adequate context for an agent to understand what the tool does. It could mention the output format, but for a read-only env var listing, the current level is nearly 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?
The tool has zero parameters, so the input schema is empty. Per the calibration rules, a baseline score of 4 is appropriate because there is nothing for the description to clarify about 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 action ('Show') and the specific resource ('all HANA-related environment variables'), with a clear purpose ('for debugging'). This distinguishes it from sibling tools like hana_show_config or hana_show_license_info, which target different resources.
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 '(for debugging)' hint implies this is a diagnostic tool, but there is no explicit guidance on when to use it versus alternatives like hana_show_config or hana_health_check. No exclusions or alternative tool names are mentioned, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral specificity by naming the exact source view (SYS.PROCEDURE_PARAMETERS) and the returned fields, giving the agent a clear model of what happens when the tool is invoked.
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, information-dense sentence with no filler. Every word contributes to the purpose and behavioral model, making it optimally concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only metadata tool with three well-documented parameters and no output schema, the description fully covers what the tool does and what it returns. It does not need to explain defaults or error cases given the schema descriptions and strong annotations; the context is sufficiently complete.
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?
All three parameters are fully described in the input schema, so the description adds no additional parameter-level semantics. The mention of IN/OUT/INOUT refers to result content rather than input parameters, so the description does not go beyond schema coverage; baseline 3 is appropriate.
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 specifies a concrete action ('Return parameter names, types, data types, and positions') tied to a specific system view (SYS.PROCEDURE_PARAMETERS), making the tool's purpose unmistakable. It also naturally distinguishes itself from sibling tools like hana_describe_table or hana_describe_function by focusing on stored procedure parameters.
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 when a stored procedure's parameter signature is needed, and the system view reference provides context. However, it does not explicitly state when to use this tool over alternatives (e.g., hana_describe_function for functions) or mention any exclusion criteria, leaving usage guidance only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by explaining the LIMIT/OFFSET wrapping, row/column/cell caps, default blocking of INSERT/UPDATE/DELETE with env vars to enable them, and the snapshotId for pagination. These are critical behavioral traits not present in the annotations (which only indicate destructiveness).
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 dense but efficient, front-loaded with the core purpose, followed by conditional behaviors and a brief parameter note. Every sentence adds value, though it could be slightly more scannable with clearer bullet points or separation between the query-limit and write-permission sections.
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 tool's complexity (7 params, output schema, many siblings), the description covers the key behaviors: limits, write blocking, and pagination. It leaves some ambiguity about non-DML statements (e.g., DDL) when limits are enabled, but overall it is sufficiently complete for an agent to invoke it correctly in most scenarios.
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 already provides 100% coverage for parameters, so the description adds limited new meaning. It mentions 'Use limit, offset, maxRows, includeTotal as needed' but does not fundamentally expand on the schema's existing descriptions. The connection between maxRows and truncation/snapshotId is helpful but marginal.
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 opens with 'Execute SQL against HANA', a specific verb+resource that clearly defines the tool's core purpose. It further distinguishes itself from siblings by detailing the SQL execution behavior and referencing hana_query_next_page for pagination, showing it is the primary general-purpose query tool.
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 offers context about when queries are wrapped (HANA_QUERY_LIMITS_ENABLED=true) and when writes are permitted (via env vars), but it does not explicitly state when to use this tool versus alternatives like hana_get_sample_data or hana_explain_plan. It mentions hana_query_next_page as a continuation path, but lacks a clear 'use this for X, not Y' guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation as read-only, idempotent, and non-destructive. The description adds valuable context about required privileges and the underlying system view used. This matches the bar for adding auth needs and source information beyond annotations.
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 a clear front-loaded verb 'Retrieve' and resource. It includes only essential information: what it returns, target object types, source, and privilege note. 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?
For a simple retrieval tool with excellent annotations and full schema coverage, the description adequately covers purpose, supported object types, and an important prerequisite. It does not detail error handling or return format, but the DDL phrase suggests the output shape. Overall sufficiently complete.
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?
Schema description coverage is 100%, so the baseline of 3 applies. The description repeats the object type list already in the schema and adds no additional parameter-level detail. No extra semantics are needed beyond the 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 retrieves DDL (CREATE statements) for a specific list of object types from SYS.OBJECT_DEFINITION. This specific verb+resource combination distinguishes it from sibling metadata tools like describe_table and describe_view.
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 specifies the applicable object types (TABLE, VIEW, PROCEDURE, FUNCTION, TRIGGER, SEQUENCE) and mentions privilege requirements. It does not explicitly call out alternative tools, but the context makes clear when to use this DDL fetcher versus structural describers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only and non-destructive. The description adds useful behavioral details beyond annotations: it references the system view M_EXPENSIVE_STATEMENTS and indicates the result is ordered by duration, plus the MONITORING privilege requirement.
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 deliver the core purpose and a key prerequisite without any filler. The most important information is front-loaded.
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?
The description adequately covers the source, ordering, and privilege requirement. There is no output schema, but the tool is simple and the description gives enough context for an agent to invoke it appropriately. Minor gap: it does not mention what happens if the privilege is missing or the exact output shape.
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 fully documents the only parameter (limit) with its default and maximum values, so the description adds no additional parameter semantics. Baseline of 3 is appropriate since 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 identifies the tool's action ('Return'), the specific resource (M_EXPENSIVE_STATEMENTS), and the ordering ('by duration'). This distinguishes it from sibling tools like hana_realtime_performance and hana_get_session_info.
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 states the required MONITORING privilege, providing clear context for when the tool can be used. It does not explicitly name alternative tools, but the privilege and targeted resource imply a specific diagnostic use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds transparency by disclosing that disk size requires the MONITORING privilege, which is important for permission planning, and by naming the exact system views queried. It does not contradict annotations.
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?
One sentence front-loads the action and return value list, then adds the privilege caveat. No unnecessary words or redundancy.
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?
The description covers purpose, key outputs, source views, and a privilege caveat, which is adequate for a simple read-only stats tool. It does not mention behavior for missing tables or schema handling, but the schema already documents the default, and annotations cover safety. Slightly more detail about output shape would be helpful, but it is not essential.
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 already provides descriptions for both parameters, including the default for schema_name, so the description adds no additional parameter semantics. With 100% schema coverage, the baseline score of 3 applies.
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 ('Return') and clearly enumerates the exact outputs (row count, table type, column-store flag, primary key flag, disk size). It distinguishes this tool from sibling tools like hana_get_column_stats by focusing on table-level statistics and naming the source system views.
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 clearly implies when to use this tool: when table-level statistics are needed, including disk size. It does not explicitly exclude alternatives or name sibling tools, but the 'table stats' versus 'column stats' distinction is implicit. There is no misleading guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds valuable context about the snapshot TTL (HANA_QUERY_SNAPSHOT_TTL_MS) and the requirement to reuse the same SQL and parameters, which are beyond the structured annotations.
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, front-loaded sentence that states the purpose and key constraint (same SQL/params, TTL). Every word earns its place; no redundancy or filler.
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 simple pagination tool with a rich schema and output schema, the description covers the essential context: what triggers a truncated result, how to fetch the next page, and the TTL caveat. It might optionally mention the behavior on TTL expiry or that offset should come from the previous result, but the schema already hints at this.
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?
Input schema description coverage is 100%, so the baseline is 3. The description reinforces that snapshot_id comes from a previous result and that offset is typically the prior nextOffset, but these are already partially captured in the schema (e.g., 'usually prior nextOffset'). No extra enrichment beyond schema descriptions.
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 action ('Fetch the next page') and the specific resource ('a truncated SELECT using snapshotId from a previous hana_execute_query result'). It distinguishes this tool from siblings by focusing on pagination continuation, not initial query execution.
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 implies when to use the tool: after receiving a truncated result from hana_execute_query with a snapshotId. It doesn't explicitly mention alternatives, but the context is unambiguous. A minor improvement would be stating 'use this instead of re-running the query'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already indicate readOnly, idempotent, and non-destructive traits, the description adds useful behavioral context: it retrieves 'full Markdown content', supports 'local or remote' cases, and works offline even with an expired license. No contradictions with annotations.
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, no redundancy, front-loaded with the primary purpose. Every phrase adds value: 'full Markdown content', 'local or remote', and 'offline mode when license expired' are all informative without being verbose.
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 simple one-parameter tool with no output schema, the description covers the core operation and return content type ('full Markdown content'). The offline availability and local/remote scope add context. It could mention error scenarios or whether the content is wrapped in a JSON response, but overall it is sufficiently complete for an AI agent.
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 schema already covers the single parameter with a clear example. The description mentions 'by filename' and 'local or remote' but does not add significant new meaning beyond the schema. The parameter semantics are adequately handled by the schema, so a baseline 3 is appropriate.
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 specifies the exact action ('Read the full Markdown content'), the target resource ('local or remote knowledge base case'), and the key input ('by filename'). It clearly distinguishes from sibling tools like hana_search_knowledge_base (search) and hana_save_knowledge_case (write).
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 situational context—'Available even in offline mode when the license is expired'—which signals when this tool is particularly useful. However, it does not explicitly state when not to use it or mention alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation with no idempotency or destructive behavior. The description adds useful context: the knowledge base is 'local Markdown' and requires a license feature. It does not disclose potential side effects (e.g., overwriting existing cases by title), but given annotations cover the safety profile, this is acceptable. No contradiction with annotations.
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, well-structured sentence that front-loads the action and object. It contains no filler or redundancy. The license requirement is included as a necessary caveat. Every word adds value, making it highly concise and effective.
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 13 parameters but 100% schema coverage, the description sufficiently explains the tool's role and relation to siblings (save vs. read/search/generate). It does not explain return values or success behavior, but since there is no output schema and the tool is a write operation, this is a minor gap. The license requirement and target resource make it contextually complete for an agent to invoke correctly.
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?
Schema description coverage is 100%, so all 13 parameters have individual descriptions. The tool description does not add parameter-level semantics beyond what is in the schema, but it does contextualize that the tool is for saving resolved cases, implying use of solution, cause, lessons, etc. This meets the baseline for high schema coverage.
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 the specific verb 'Save' and clearly identifies the resource: 'local Markdown knowledge base'. It further specifies the context ('a resolved incident or finding'), which distinguishes it from sibling tools like hana_read_kb_case, hana_search_knowledge_base, and hana_generate_kb_index. The purpose is immediately clear and unambiguous.
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 states when to use the tool: to save a resolved incident or finding. It also provides a condition: 'requires active knowledge-base license feature', which is a usage prerequisite. However, it does not explicitly mention alternatives or when not to use it (e.g., 'use hana_search_knowledge_base to search existing cases'), but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a read-only, idempotent operation, and the description adds the underlying system view (SYS.TABLE_COLUMNS) and a hard result cap of 1000. These are meaningful, non-obvious behavioral details that go beyond the annotations.
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 just three concise clauses that front-load the action and include key constraints (LIKE pattern, schema filter, 1000 cap) with zero wasted words. It is ideal in length and structure.
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 simple search tool with good annotation coverage, the description covers the source and the result cap. The lack of an output schema means the description could optionally clarify what fields are returned, but this is a minor gap given the tool's straightforward purpose.
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?
All three parameters are fully documented in the schema (100% coverage), so the description adds no additional parameter-level detail. The description's scope phrasing aligns with the schema, but does not go beyond the baseline expected from well-documented 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 a specific action ('Find all columns matching a LIKE pattern') with a defined resource scope ('across all tables or within a schema'), distinguishing it from sibling search tools like hana_search_tables. Including the data source and result cap adds further clarity.
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 implies clear usage context via the LIKE pattern and the optional schema filter, but it does not explicitly name alternative tools or exclusions. It provides enough context for an agent to choose it over similar list/describe tools, though it lacks direct comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context by specifying exactly what data is shown (license status, hardware ID, plan, expiration), which is not in the annotations. It does not mention any special permissions or output format, but for a zero-parameter read-only tool, this is 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?
The description is a single concise sentence of nine words that directly states the tool's function. It covers all key details without extraneous information, achieving maximum efficiency and front-loading.
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 simple read-only tool with zero parameters and strong annotations, the description is complete enough. It lists the specific data points returned, compensating somewhat for the lack of an output schema. While it does not describe the output format (e.g., table layout), that is less critical for this straightforward status 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?
The input schema has no parameters, so there is nothing to document. According to the rubric, zero parameters receive a baseline score of 4. The description does not need to add parameter information because there are none to describe.
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 function with a specific verb ('Show') and resource ('current license status, hardware ID, plan and expiration'). This is distinct from sibling tools like hana_show_config or hana_show_env_vars, which address different information. The level of detail leaves no ambiguity about the tool's purpose.
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 through its content (license-related details), but it does not explicitly say when to use this tool over alternatives or mention any exclusions. Unlike the TDQS example that names alternative search tool, there is no direct guidance, though the name and sibling list provide context. This is implied usage at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds the behavior of checking a vendor license server, which is a small extra context. It does not disclose network latency, authentication, or return format, but the annotations cover the safety profile.
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 that contains no fluff. Every word contributes to the meaning, and it is easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless tool with good annotations, the description is sufficient. It explains the purpose and source, and the output schema is not provided, so no return documentation is expected. The simplicity makes this 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 tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics and does not add misleading information.
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 a specific action ('Check if a newer version') and resource ('HANA MCP client') from a defined source ('vendor license server'). It distinguishes itself from the sibling tool 'hana_apply_update' by focusing on the check, not the update application.
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 implies the tool is used to determine update availability, and the presence of the sibling 'hana_apply_update' clarifies its role as a pre-update check. It does not explicitly state 'when not to use' or name alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by explaining the two data sources (SYS.COLUMN_STATISTICS vs live COUNT queries), which implies potential performance differences and the requirement for column_name in live mode. This goes beyond the annotations and adequately discloses 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?
The description is two sentences, front-loaded with the primary action, and contains no filler. It efficiently conveys the two modes, the required input condition, and the output scope in minimal words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, full schema descriptions, and strong annotations (read-only, idempotent, non-destructive), the description is complete. It covers both operational modes and the constraint, and no output schema is needed for this straightforward retrieval tool.
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?
Schema description coverage is 100%, so the schema already documents all parameters, including 'column_name' being required when live=true. The description reinforces the live/column_name relationship but does not add new semantics beyond the schema, thus baseline 3 is appropriate.
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 verb 'Retrieve' and the resource 'column statistics' with specific fields (distinct count, null count, min/max). It distinguishes itself from sibling tool hana_get_table_stats by focusing on column-level rather than table-level statistics, and the two execution modes (cached vs live) are explicit.
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 clear context on when to use cached mode vs live=true, and explicitly states that live=true requires a specific column_name. It does not name alternatives explicitly, but the distinction is evident from the tool name and sibling list, earning a 4 for clear guidance without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds valuable context: the data source (SYS.OBJECT_DEPENDENCIES) and the row limit (capped at 200 rows), which are behavioral traits not present in annotations.
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?
One concise sentence with essential information, front-loaded with the purpose, followed by source and limit. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter tool with full schema descriptions and safety annotations, the description provides purpose, source, and a critical limit. No output schema exists, but the tool is simple enough; no major gaps.
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?
Schema description coverage is 100%, so all parameters (object_name, direction, schema_name) have descriptions. The description's phrase 'what an object depends on or what depends on it' aligns with the 'direction' parameter but adds no new semantic detail beyond the 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's function: 'Show what an object depends on or what depends on it', with a specific source (SYS.OBJECT_DEPENDENCIES) and a key limitation (capped at 200 rows). This is a specific verb+resource that distinguishes it from sibling tools like hana_describe_table or hana_explain_plan.
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 implies usage for exploring dependencies, but does not explicitly state when to use it over alternatives or mention exclusions. Given the sibling list lacks another dependency-focused tool, the context is clear enough, though it could be improved with explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior, so the bar is lower. The description adds valuable context by naming the system view (SYS.TABLE_PARTITIONS) and the specific returned fields, plus the empty-result behavior for unpartitioned tables. This goes beyond the annotations without over-explaining.
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, front-loaded with the action and resource, and every word adds value. The first sentence states the core purpose, and the second covers an important edge case. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only query with 2 parameters and full schema coverage, the description is complete: it names the source view, lists the returned metadata fields, and handles the unpartitioned-table case. No output schema exists, but the listed fields give agents sufficient understanding of what to expect.
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?
Schema description coverage is 100%, with both table_name and schema_name adequately described in the input schema. The tool description itself adds no parameter-level details, so the baseline of 3 applies; the schema already carries the semantic weight.
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 the specific verb 'Return' and clearly identifies the resource: partition metadata from SYS.TABLE_PARTITIONS. It lists the exact metadata fields (type, level, record count, loaded state), which distinguishes it from sibling tools like hana_get_table_stats or hana_describe_table.
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 clearly implies when to use the tool (when partition metadata is needed) and notes an important edge case: returns empty for unpartitioned tables. However, it does not explicitly name alternative tools or state when not to use it beyond that edge case, falling short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds a minor behavioral detail by specifying the source tables (DUMMY and M_DATABASE), but does not elaborate on potential errors, limitations, or response format, which is acceptable given the annotations.
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, tightly worded sentence that front-loads the verb and lists exactly what the tool returns. Every word earns its place—there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only informational tool with no output schema, the description is complete. It enumerates all returned values and their sources, making it sufficient for an agent to understand the tool's behavior without further elaboration.
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 tool has zero parameters, and schema coverage is 100% (empty schema). The description provides a baseline of 4 for zero-parameter tools, adding no param info because none exists. It correctly lists the returned fields, which is the only semantics 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?
The description explicitly states the tool returns CURRENT_USER, CURRENT_SCHEMA, connected database name, SYSTEM_ID, and HANA version from DUMMY and M_DATABASE. This is a specific verb+resource combination that clearly distinguishes it from sibling tools like hana_test_connection or hana_show_config, which serve different purposes.
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 makes the usage context obvious: use when you need current session information such as user, schema, database, or version. It does not explicitly name alternatives or exclusions, but the specificity of the returned fields provides clear context for when this tool is appropriate compared to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context beyond those annotations: the auth requirement (CATALOG READ privilege) and the fallback to CURRENT_USER when grantee is omitted. This is useful situational detail, though no return format is described (but no output schema exists either).
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, front-loaded with the core action and source, and includes essential permission context. No filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description is complete: it covers the action, the source system view, the permission requirement, and the default behavior when grantee is omitted. Sibling context confirms this is a standalone listing tool, and nothing critical is missing.
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 schema already fully describes the only parameter 'grantee' ('Database user to query. Omit for current user.'), providing 100% schema description coverage. The tool description echoes this same information without adding any new semantic details, so the schema carries the full burden.
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 function: 'List effective privileges for a user (or CURRENT_USER if omitted) from SYS.EFFECTIVE_PRIVILEGES.' It uses a specific verb ('List') and a specific resource ('effective privileges'), and names the exact system view. This distinguishes it from sibling listing tools like hana_list_tables and hana_list_schemas.
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 clear operational context by stating the prerequisite ('Requires CATALOG READ privilege or querying own privileges') and explaining the optional grantee behavior (CURRENT_USER if omitted). It does not explicitly name alternative tools or exclusion scenarios, but the context is sufficient for an agent to determine when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful context beyond annotations: it specifies the schema source (_SYS_BIC) and the support for prefix filtering and pagination, which are behavioral traits the agent needs to know.
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 the main purpose front-loaded and no irrelevant detail. Every word adds value.
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 simple list tool with good annotations and no output schema, the description is complete enough: it identifies the source schema, the item type, and key capabilities. It lacks details on return format or ordering, but those are not critical for selection.
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?
Schema coverage is low (only prefix has a description). The description compensates by explicitly mentioning 'prefix filter' and 'pagination', which explains the roles of limit/offset and prefix. This adds meaning beyond the bare schema, though it could detail limits or defaults.
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 ('List') and resource ('calculation views from the _SYS_BIC schema'), with context (SAP BW/S4 analytical views). This clearly distinguishes it from sibling tools like hana_list_views and hana_search_tables.
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 clearly indicates the intended use case (SAP BW/S4 analytical views) and implicitly distinguishes it from generic view listing. It does not explicitly name alternatives or exclusions, but the context is specific enough to guide tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds behavioral context about pagination via 'HANA_LIST_DEFAULT_LIMIT / offset', which is not present in the schema and informs the agent about default limits. This complements the annotations rather than repeating them.
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: 'List schemas in the HANA database with optional prefix filter and pagination (HANA_LIST_DEFAULT_LIMIT / offset).' It covers the core action, optional filters, and a pagination detail without any extraneous 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?
For a straightforward list operation, the description adequately covers the main functionality, optional parameters, and pagination. An output schema exists to detail return structure, so the description does not need to explain that. A slight gap is the lack of explicit statement about default behavior when no parameters are provided, but this is easily inferred from 'optional' and the 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?
Schema coverage is 100%, so the baseline is 3. The description adds value by referencing 'HANA_LIST_DEFAULT_LIMIT', which clarifies that the limit parameter has a server-side default—information not in the schema's field descriptions. It also ties the three parameters together into a coherent feature set (prefix filter and pagination).
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 is highly specific: 'List schemas in the HANA database' clearly identifies the verb and resource, distinguishing it from sibling tools like hana_list_tables and hana_list_views. It also mentions optional prefix filtering and pagination, adding scope beyond a bare tautology.
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 implicitly conveys when to use this tool: whenever schema enumeration is needed. While it does not explicitly exclude alternatives or name competing tools, the sibling names (e.g., hana_list_tables, hana_list_views) make the distinct use case obvious. The context is clear enough without explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral details: it uses SYS.TABLES and caps results at 2000, which are not conveyed by annotations. This exceeds the baseline for annotation coverage.
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 concise sentences, front-loaded with the primary action. Each sentence provides distinct value: purpose, mechanics, and result cap. 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?
For a search tool with 3 parameters and no output schema, the description covers the essential behavioral aspects: pattern matching, schema scope, source table, and result cap. It does not detail return format, but that is not critical for a search operation. Sibling differentiation is implied, though explicit alternatives would 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?
Schema covers all 3 parameters with descriptions, but the description adds meaning: it clarifies that omitting schema_name searches all schemas, and that limit has a hard cap of 2000. This goes beyond just restating schema fields.
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 purpose: finding tables via a LIKE pattern across all schemas or a specific one. It distinguishes itself from sibling tools like hana_list_tables (which lists all tables) and hana_search_columns (which searches columns), using specific verbs and resource scope.
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 on when to use: when searching for tables by name pattern. It mentions the optional schema filter and the default all-schema behavior. However, it does not explicitly name alternatives or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![sap-hana-mcp-server MCP server](https://glama.ai/mcp/servers/josecarlos3390/sap-hana-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/josecarlos3390/sap-hana-mcp-server)

Score Badge

Copy to your README.md:

[![sap-hana-mcp-server MCP server](https://glama.ai/mcp/servers/josecarlos3390/sap-hana-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/josecarlos3390/sap-hana-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/josecarlos3390/sap-hana-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server