Firebird データベース用の Anthropic の MCP (Model Context Protocol) の実装。
https://github.com/user-attachments/assets/e68e873f-f87b-4afd-874f-157086e223af
Related MCP server: MSSQL MCP Server
MCP Firebirdは、Firebird SQLデータベース向けにAnthropicのモデルコンテキストプロトコル（MCP）を実装したサーバーです。これにより、Claudeのような大規模言語モデル（LLM）は、Firebirdデータベース内のデータに安全かつ制御された方法でアクセス、分析、操作できるようになります。
SQLクエリ: FirebirdデータベースでSQLクエリを実行する
スキーマ分析: テーブル、列、関係に関する詳細情報を取得します
データベース管理: バックアップ、復元、検証操作を実行する
パフォーマンス分析: クエリのパフォーマンスを分析し、最適化を提案します
複数のトランスポート: STDIO および SSE (Server-Sent Events) トランスポートをサポート
Claude 統合: Claude Desktop およびその他の MCP クライアントとシームレスに連携します
VSCode 統合: Visual Studio Code で GitHub Copilot と連携
セキュリティ: SQLクエリ検証とセキュリティ構成オプションが含まれます
# Global installation
npm install -g mcp-firebird
# Run the server
npx mcp-firebird --database /path/to/database.fdbバックアップ/復元操作を行うには、Firebirdクライアントツールをインストールする必要があります。詳細については、 「完全インストール」をご覧ください。
VSCode と GitHub Copilot の統合については、 「VSCode の統合」を参照してください。
Claude Desktop の構成を編集します。
code $env:AppData\Claude\claude_desktop_config.json # Windows
code ~/Library/Application\ Support/Claude/claude_desktop_config.json # macOSMCP Firebird 構成を追加します。
{
"mcpServers": {
"mcp-firebird": {
"command": "npx",
"args": [
"mcp-firebird",
"--host",
"localhost",
"--port",
"3050",
"--database",
"C:\\path\\to\\database.fdb",
"--user",
"SYSDBA",
"--password",
"masterkey"
],
"type": "stdio"
}
}
}Claudeデスクトップを再起動します
# Start with SSE transport
npx mcp-firebird --transport-type sse --sse-port 3003 --database /path/to/database.fdbSmithery経由で Claude Desktop 用の MCP Firebird を自動的にインストールするには:
npx -y @smithery/cli install @PuroDelphi/mcpFirebird --client claude詳しい情報については、次のドキュメントを確認してください。
MCP Firebird が仕事やプロジェクトに役立つと感じられた場合は、ぜひ寄付を通じて開発へのご支援をご検討ください。皆様のご寄付は、このツールの維持と改善に役立ちます。
GitHub スポンサー: @PuroDelphi をスポンサーする
PayPal : PayPal経由で寄付する
このプロジェクトを支援するもう一つの素晴らしい方法は、 Aistentes Autónomosを通じて当社のAIエージェントを雇用することです。当社は、様々なビジネスニーズに特化したAIアシスタントを提供し、タスクの自動化と生産性向上を支援します。
⭐寄付者、スポンサー、そしてクライアントの皆様には、問題解決、機能リクエスト、実装ガイダンスなどに関する優先的なサポートと支援を提供いたします。私たちはすべてのユーザーの皆様を支援するよう努めておりますが、プロジェクトに資金的にご支援いただいた方には、より迅速な対応と専用のサポートを提供いたします。
皆様のサポートは大変ありがたく、MCP Firebird の継続的な開発に役立ちます。
このプロジェクトは MIT ライセンスに基づいてライセンスされています - 詳細についてはLICENSEファイルを参照してください。
Analyzes a SQL query to identify missing indexes that could improve performance
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | SQL query to analyze for missing indexes |
| Name | Required | Description |
|---|---|---|
| error | No | Failure information; present when success is false |
| result | No | The legacy JSON payload; present for completed operations and partial batches |
| success | Yes | False for tool failures, including partially failed batches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds no behavioral context beyond the annotations and output schema, saying nothing about cost, analysis scope, or caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the purpose is stated immediately and nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need not be explained, and the tool is simple with one documented param. However, the complete absence of usage context and prerequisites leaves it only minimally complete for an agent deciding whether to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter with 100% schema description coverage, so the schema fully documents the 'sql' input. The description adds no format, length, or dialect guidance beyond the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: analyzes a SQL query to find missing indexes for performance. Clear what it does. It does not, however, distinguish itself from near-neighbors like analyze-query-performance or get-execution-plan, which an agent might reasonably confuse it with.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites (e.g., that the referenced objects/tables must exist), and no mention of the related performance siblings. The agent must infer context solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyzes the performance of a SQL query by executing it multiple times and measuring execution time
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | SQL query to analyze | |
| params | No | Parameters for parameterized queries | |
| iterations | No | Number of times to run the query for averaging performance |
| Name | Required | Description |
|---|---|---|
| error | No | Failure information; present when success is false |
| result | No | The legacy JSON payload; present for completed operations and partial batches |
| success | Yes | False for tool failures, including partially failed batches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true. The description adds the key behavioral detail of repeated execution, which plausibly explains the destructive flag, but it does not warn that executing a mutating SQL statement multiple times can have compounding side effects. Given annotations carry the safety profile, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence with the mechanism front-loaded and no filler. It could arguably use one more sentence given the tool's destructive nature, but nothing present is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described. However, for a destructive, non-idempotent tool that executes arbitrary SQL repeatedly, the description omits any caution about mutating queries and does not route the agent to cleaner alternatives such as get-execution-plan.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so sql, params, and iterations are fully documented in the schema itself. The description's 'executing it multiple times' loosely echoes the iterations parameter but adds no format or syntax detail beyond it. Baseline 3 applies when the schema does the explaining.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (analyzes performance) and resource (SQL query), and clarifies the mechanism (repeated execution with timing measurement). It does not, however, distinguish itself from siblings like get-execution-plan or execute-query, which a reader would have to infer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus get-execution-plan (which likely analyzes performance without executing) or execute-query. There is no statement of preconditions or exclusions, leaving the agent to guess based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyzes statistical information about a table including row count, column statistics, and data distribution.
| Name | Required | Description | Default |
|---|---|---|---|
| tableName | Yes | Name of the table to analyze |
| Name | Required | Description |
|---|---|---|
| error | No | Failure information; present when success is false |
| result | No | The legacy JSON payload; present for completed operations and partial batches |
| success | Yes | False for tool failures, including partially failed batches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only the content of the analysis; it omits that statistics computation can be an expensive/heavy operation and whether results are cached or live-sampled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One efficient sentence with the resource and returned information front-loaded and no filler. It is well-sized for a single-parameter read tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and annotations covering safety, the description need not explain return values. The remaining gap is the cost/behavioral profile of statistics analysis, which is minor for a low-complexity, single-input read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single tableName parameter, so the schema already carries the parameter semantics. The description adds nothing about naming conventions, qualification, or lookup behavior beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Analyzes') and resource ('a table') and enumerates the outputs (row count, column statistics, data distribution), which distinguishes it from the descriptive siblings like describe-table. However, it never names or contrasts with those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no indication of when to use this tool versus describe-table or get-table-data, no prerequisites, and no exclusions. 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.
Gets the detailed schema of multiple tables in parallel for improved performance.
| Name | Required | Description | Default |
|---|---|---|---|
| tableNames | Yes | Array of table names to describe | |
| maxConcurrent | No | Maximum number of concurrent operations (default: 5) |
| Name | Required | Description |
|---|---|---|
| error | No | Failure information; present when success is false |
| result | No | The legacy JSON payload; present for completed operations and partial batches |
| success | Yes | False for tool failures, including partially failed batches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile, so the description only needs to add extra context. It does add that execution is parallel "for improved performance," which is useful beyond the annotations, but it omits the batch bound (max 20 tables) and how partial failures are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with the batch/parallel scoping front-loaded and no filler. It is appropriately sized, though it is arguably under-specified rather than maximally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained. For a read-only batch tool whose annotations cover safety and whose schema covers parameters, the description is adequate, though a note on batch limits or partial failure behavior would close the remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters (tableNames, maxConcurrent) are documented in the schema, so the baseline is 3. The description adds no formatting, ordering, or batching semantics beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb ("Gets the detailed schema") plus resource ("multiple tables in parallel"), which implicitly distinguishes it from the sibling describe-table. It stops short of naming the single-table alternative explicitly, so an agent must infer the batch-vs-single distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase "multiple tables in parallel" implies when to reach for this tool instead of describe-table, but there is no explicit when-to-use statement, no exclusion, and no naming of the alternative. Usage is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets detailed information about a specific function, including its source code (for PSQL functions)
| Name | Required | Description | Default |
|---|---|---|---|
| functionName | Yes | Name of the function to describe |
| Name | Required | Description |
|---|---|---|
| error | No | Failure information; present when success is false |
| result | No | The legacy JSON payload; present for completed operations and partial batches |
| success | Yes | False for tool failures, including partially failed batches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds one genuinely useful behavioral detail — that source code is returned for PSQL functions — which hints at potentially large/sensitive output, but says nothing about behavior for non-PSQL functions or error cases (e.g., unknown name).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action and resource, with the qualifier placed where it belongs. No filler or restated boilerplate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return-field documentation is unnecessary, and the sole required parameter is fully covered by the schema. The description is adequate for a simple read tool; the only gap is the absence of any usage/alternative guidance, which is a minor omission at this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a single documented parameter, so the schema carries the load and baseline 3 applies. The description adds no extra meaning such as schema-qualification, case sensitivity, or overload disambiguation for the functionName argument.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Gets) and resource (detailed information about a specific function), and the parenthetical about source code clarifies what 'detailed information' includes. It is clearly distinguishable in intent from list-functions and describe-procedure, though it never names a sibling to reinforce that contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the name and the word 'specific' — an agent can infer this is the lookup tool for one function versus listing tools. There is no explicit when-to-use, when-not-to-use, or named alternative (e.g., list-functions for enumerating).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets detailed information about a specific package, including its header and body source
| Name | Required | Description | Default |
|---|---|---|---|
| packageName | Yes | Name of the package to describe |
| Name | Required | Description |
|---|---|---|
| error | No | Failure information; present when success is false |
| result | No | The legacy JSON payload; present for completed operations and partial batches |
| success | Yes | False for tool failures, including partially failed batches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered. The description adds that the response includes header and body source, which is a modest behavioral detail beyond the annotations, but says nothing about size, permissions, or paging of large source bodies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. The key content (what is returned) follows immediately after the verb+resource, and nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema, full parameter coverage, and complete annotations, the description supplies everything needed to call the tool correctly. The only missing element is explicit disambiguation from list-packages and sibling describe-* tools, which is minor for a single-param read.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single packageName parameter, so the schema already documents it fully. The description adds no naming/format guidance beyond what the schema provides; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Gets detailed information) and resource (a specific package), and even specifies what the detail comprises (header and body source). It is clearly distinguishable from the describe-* siblings by resource, though it never explicitly contrasts with list-packages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the name/verb pattern. There is no explicit guidance on when to use this versus list-packages (for enumeration) or the other describe-* tools. An agent can infer intent but gets no stated conditions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets detailed information about a specific stored procedure, including its source code and parameters
| Name | Required | Description | Default |
|---|---|---|---|
| procedureName | Yes | Name of the stored procedure to describe |
| Name | Required | Description |
|---|---|---|
| error | No | Failure information; present when success is false |
| result | No | The legacy JSON payload; present for completed operations and partial batches |
| success | Yes | False for tool failures, including partially failed batches |
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 fully covered elsewhere. The description adds only that source code and parameters are returned, which is mild value given an output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence with the verb and resource front-loaded and a useful enumeration of returned content. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with full schema coverage, complete annotations, and an output schema, the description covers what is needed. The only gap is routing guidance relative to list-procedures and the other describe-* siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and there is a single required parameter, so the schema fully documents procedureName. The description adds no naming, format, casing, or qualification guidance beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (gets detailed information) and resource (a specific stored procedure) and enumerates the concrete payload (source code and parameters). It is clearly distinguishable from list-procedures in intent, though it never names that sibling or others in the describe-* family.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer this follows list-procedures when details are needed, but the description gives no explicit when-to-use condition, prerequisites, or alternatives for the other describe-* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets the detailed schema (columns, types, etc.) of a specific table.
| Name | Required | Description | Default |
|---|---|---|---|
| tableName | Yes | Name of the table to describe |
| Name | Required | Description |
|---|---|---|
| error | No | Failure information; present when success is false |
| result | No | The legacy JSON payload; present for completed operations and partial batches |
| success | Yes | False for tool failures, including partially failed batches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds only the nature of the returned content, with no mention of behavior on missing tables or permissions, which is acceptable given the 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
One tight sentence that front-loads the action and resource with zero filler. It is appropriately sized, though it is on the sparse side rather than maximally informative for the space available.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a full output schema, complete annotations, and a fully documented single parameter, the description is adequate for an agent to call the tool correctly. Only minor gaps remain, such as error behavior when the table does not exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a single self-documenting parameter (tableName). The description adds no format, qualification, or naming-convention detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (gets/describes) and resource (schema of a specific table) with concrete examples of what is returned (columns, types). It does not, however, distinguish itself from close siblings such as describe-batch-tables or get-field-descriptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'of a specific table' implicitly signals single-table use versus the batch sibling, but there is no explicit when-to-use guidance, no prerequisites, and no named alternatives. Usage is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets detailed information about a specific trigger, including its source code, type, sequence, and status
| Name | Required | Description | Default |
|---|---|---|---|
| triggerName | Yes | Name of the trigger to describe |
| Name | Required | Description |
|---|---|---|
| error | No | Failure information; present when success is false |
| result | No | The legacy JSON payload; present for completed operations and partial batches |
| success | Yes | False for tool failures, including partially failed batches |
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 fully covered without the description. The description adds useful content disclosure (source code, type, sequence, status), though with an output schema present that detail is somewhat redundant; no pagination, permissions, or error behavior is discussed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the verb and payload description, with no filler. It could arguably be trimmed since the listed fields overlap with the output schema, but every clause is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one required parameter at full schema coverage, rich annotations, and an output schema handling return values, the description supplies everything an agent needs to invoke the tool correctly. The only missing element is routing guidance relative to the many sibling list/describe tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter with 100% schema description coverage, so the schema fully documents 'triggerName'. The description adds no syntax, naming convention, or case-sensitivity guidance beyond what the schema states, which is the expected baseline here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb ('Gets detailed information') plus a precise resource ('a specific trigger'), and it enumerates the content returned (source code, type, sequence, status). It does not, however, distinguish itself from siblings like list-triggers or get-table-triggers, so an agent must infer that 'a specific trigger' implies single-item lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the phrase 'a specific trigger' suggests this is the single-item counterpart to list-triggers, but no alternative tool is named and no condition for choosing between them is stated. Adequate minimum viability, no explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Echoes back the input message
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | The message to echo back |
| Name | Required | Description |
|---|---|---|
| error | No | Failure information; present when success is false |
| result | No | The legacy JSON payload; present for completed operations and partial batches |
| success | Yes | False for tool failures, including partially failed batches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, fully covering the safety profile. The description adds no behavioral context beyond confirming it returns the input, so it contributes little value on top of the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with no filler and the core behavior front-loaded. It is appropriately sized for a trivial tool, though it is so sparse that it borders on under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a trivial echo utility, the description plus rich annotations, full schema coverage, and an output schema cover essentially everything an agent needs. Only the absence of stated use-cases keeps it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With a single parameter and 100% schema description coverage, the schema already documents 'message'. The description adds nothing about format, limits, or handling beyond what the schema provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Echoes back the input message" is a clear verb+resource and matches the tool's behavior, but the name 'echo' already conveys the same thing, making the description largely a restatement. It does not distinguish this utility tool from the many database-oriented siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no indication of when to use this tool, when not to, or what alternatives exist. Given it sits among database/query tools, some guidance on its test/utility role would be valuable but is entirely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Executes multiple SQL queries in parallel for improved performance.
| Name | Required | Description | Default |
|---|---|---|---|
| queries | Yes | Array of query objects, each containing SQL and optional parameters | |
| maxConcurrent | No | Maximum number of concurrent queries (default: 5) |
| Name | Required | Description |
|---|---|---|
| error | No | Failure information; present when success is false |
| result | No | The legacy JSON payload; present for completed operations and partial batches |
| success | Yes | False for tool failures, including partially failed batches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, openWorldHint=true, and non-idempotent, so the safety profile is covered. The description adds that queries run in parallel for performance, a useful trait not in the annotations, but omits critical batch behaviors such as partial-failure handling, atomicity, and whether one failed query aborts the rest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with the key qualifier ('in parallel for improved performance') front-loaded and zero filler. Appropriately sized, though it could trade a few words for missing usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists and annotations cover the destructive/open-world profile, so return values and safety need not be described. Still, for a destructive parallel-execution tool the description omits failure semantics and the batching-vs-single-query decision, leaving real gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, including nested sql/params and maxConcurrent, so the schema carries the meaning. The description's 'in parallel' loosely hints at the maxConcurrent control but adds no syntax or semantic detail beyond the structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Executes') and resource ('multiple SQL queries in parallel'), making the batch semantics clear. However, it never explicitly distinguishes itself from the sibling execute-query tool, so an agent must infer the difference from the name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no conditions under which batching beats calling execute-query repeatedly, and no mention of the obvious alternative. The agent gets no routing help beyond the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Executes a SQL query in the Firebird database. Uses FIRST/ROWS for pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | SQL query to execute (Firebird uses FIRST/ROWS for pagination instead of LIMIT) | |
| params | No | Parameters for parameterized queries to prevent SQL injection |
| Name | Required | Description |
|---|---|---|
| error | No | Failure information; present when success is false |
| result | No | The legacy JSON payload; present for completed operations and partial batches |
| success | Yes | False for tool failures, including partially failed batches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=true, openWorldHint=true, and idempotentHint=false, so safety is covered externally. However, the description adds no behavioral context of its own for a tool that can mutate or drop data — nothing about transactions, commit behavior, multi-statement handling, or error semantics on partial failure. The pagination sentence duplicates the schema rather than disclosing new behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the core action front-loaded and no filler. It is efficient, though the second sentence is redundant with the schema's 'sql' description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, but a destructive, non-idempotent query tool should state commit/rollback behavior and whether DDL/DML is permitted. None of that is present, leaving material gaps for an agent about to run arbitrary SQL.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both 'sql' and 'params', including the injection-prevention note and the FIRST/ROWS pagination detail. The description merely repeats the pagination point, adding nothing the schema does not already say; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Executes a SQL query in the Firebird database'), which is clear on its own. It does not explicitly distinguish itself from the closest sibling, execute-batch-queries, so the agent must infer the single-vs-batch split.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no mention of when to prefer execute-batch-queries, and no prerequisites or cautions given for a tool whose annotations mark it destructive. The agent receives no routing help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves general information about the connected Firebird database.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| error | No | Failure information; present when success is false |
| result | No | The legacy JSON payload; present for completed operations and partial batches |
| success | Yes | False for tool failures, including partially failed batches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that baseline — no note on connection/auth requirements, latency, or the fact that results reflect the currently connected database only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler or redundancy. It is efficiently sized, though its brevity is partly the same under-specification noted elsewhere rather than deliberate economy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values do not need to be described, and there are no parameters to cover. What remains missing is any hint of what "general information" encompasses or how it differs from get-server-info, which leaves a real gap for tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so per the rubric this is the baseline of 4. There is no parameter surface for the description to explain, and nothing is misrepresented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
It names a specific verb and resource (retrieves info about the connected Firebird database), so the target is unambiguous. But "general information" is vague about what is actually returned, and it gives no differentiation from the closely related sibling get-server-info, leaving the agent to guess which one it wants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no when-to-use guidance, no prerequisites, and no mention of alternatives. With siblings like get-server-info, system-health-check, and list-tables present, an agent gets no help deciding when this tool is the right call versus those.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets the execution plan for a SQL query to understand how the database will execute it
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | SQL query to analyze | |
| params | No | Parameters for parameterized queries |
| Name | Required | Description |
|---|---|---|
| error | No | Failure information; present when success is false |
| result | No | The legacy JSON payload; present for completed operations and partial batches |
| success | Yes | False for tool failures, including partially failed batches |
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 no behavioral context beyond the title's purpose: nothing about whether the query is actually executed, cost, caching, or permission requirements. It is essentially a restatement of the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with zero waste and the purpose front-loaded. Slight deduction because it is arguably too terse for the tool it describes, but structurally sound.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description need not explain the returned plan. For a simple two-parameter read-only tool this is barely complete, but it leaves the agent to infer whether the query runs, how to compare against analyze-query-performance, and what formats are accepted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'sql' and 'params' documented in the schema itself. The description adds no meaning about parameterized-query placeholders or array ordering, so the baseline 3 for full schema coverage applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (gets) and resource (execution plan for a SQL query) plus the intent (understand how the database will execute it). It is distinguishable from execute-query and analyze-query-performance, though it never names them, so sibling differentiation is only implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the purpose — reach for this when you want a plan rather than results — but there is no explicit when-to-use statement, no exclusions, and no pointer to analyze-query-performance or execute-query as alternatives. Adequate minimum, clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets the stored descriptions for fields of a specific table (if they exist).
| Name | Required | Description | Default |
|---|---|---|---|
| tableName | Yes | Name of the table to get field descriptions for |
| Name | Required | Description |
|---|---|---|
| error | No | Failure information; present when success is false |
| result | No | The legacy JSON payload; present for completed operations and partial batches |
| success | Yes | False for tool failures, including partially failed batches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint: false, and openWorldHint: false, covering the safety profile. The description adds the useful qualifier '(if they exist)', implying the result may be empty for fields without stored descriptions, but it does not disclose return format or other behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant or filler text. It efficiently conveys the core operation and the optional-availability caveat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with full schema coverage, rich annotations, and an output schema, the description is nearly complete. It could add a bit more context about the nature of 'stored descriptions' or what happens when none exist, but nothing critical is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single parameter 'tableName' is already documented in the schema. The description adds no syntax, format, or validation details beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Gets') and resource ('stored descriptions for fields of a specific table'), making the operation clear. However, it does not explicitly distinguish this tool from sibling tools like 'describe-table', which may also expose field metadata, so the agent must infer the distinction from context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit when-to-use or when-not-to-use guidance, nor does it name alternatives or prerequisites. It merely states the purpose, leaving the agent to infer that this tool is appropriate when field descriptions are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets information about the Firebird MCP server and its available tools
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| error | No | Failure information; present when success is false |
| result | No | The legacy JSON payload; present for completed operations and partial batches |
| success | Yes | False for tool failures, including partially failed batches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered without the description. The description adds only the scope of what is returned (server info plus available tools), and with an output schema present the return shape needn't be restated. Adequate but thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence that is front-loaded with the verb and resource and contains no filler. Nothing could be cut without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a read-only annotation set and an output schema, the description doesn't need to explain returns, and zero params keep the call trivial. The remaining gap is disambiguation from the overlapping tool-listing and server-info siblings, which the description does not address.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. Schema coverage is irrelevant here since the schema is empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Gets information about') and a specific resource ('the Firebird MCP server and its available tools'), so the agent knows exactly what the tool returns. However, it offers no differentiation from close siblings such as list-available-tools, get-tool-help, get-database-info, or system-health-check, which all plausibly return server/tool information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to call this versus the several siblings that also surface tool/server information (list-available-tools, get-tool-help, get-database-info, system-health-check). Usage must be inferred entirely from the name, which is a real risk in a 31-tool server.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns PRIMARY KEY, FOREIGN KEY, UNIQUE, NOT NULL, and CHECK constraints for a table, including constrained columns and references.
| Name | Required | Description | Default |
|---|---|---|---|
| tableName | Yes | Name of the table whose relational metadata should be returned |
| Name | Required | Description |
|---|---|---|
| error | No | Failure information; present when success is false |
| result | No | The legacy JSON payload; present for completed operations and partial batches |
| success | Yes | False for tool failures, including partially failed batches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds only the scope of returned metadata, which largely duplicates what the output schema would carry; no notes on permissions, missing tables, or behavior for views.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that states the resource first and the coverage second, with no filler or redundant qualifiers. Appropriately sized for a one-parameter read tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return-value detail is already documented, and annotations cover the safety profile, so the description only needs to identify scope. It does that well, though the constraint enumeration is somewhat redundant with the output schema and nothing is said about failure behavior for unknown tables.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and there is a single required parameter (tableName), so the schema already explains the parameter fully. The description adds no casing, qualification, or lookup semantics beyond what the schema provides, making 3 the correct baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb (Returns) and resource (table constraints) and enumerates the exact constraint categories covered (PRIMARY KEY, FOREIGN KEY, UNIQUE, NOT NULL, CHECK). An agent can immediately distinguish this from siblings like get-table-indexes or get-table-triggers without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the resource name and the enumerated constraint types, but the description never states when to prefer this over describe-table, get-table-indexes, or get-table-triggers, nor any prerequisite (e.g. table must exist). Adequate but leaves routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves data from a specific table with optional filtering, pagination, and ordering.
| Name | Required | Description | Default |
|---|---|---|---|
| skip | No | Number of rows to skip | |
| first | No | Number of rows to retrieve (maximum: 1000) | |
| filters | No | Structured filters; values are always parameterized | |
| orderBy | No | ||
| tableName | Yes | Name of the table to retrieve data from |
| Name | Required | Description |
|---|---|---|
| error | No | Failure information; present when success is false |
| result | No | The legacy JSON payload; present for completed operations and partial batches |
| success | Yes | False for tool failures, including partially failed batches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds only that filtering/pagination/ordering are optional; it does not disclose the 1000-row cap, default page size, or how filters combine, which would have been genuinely additive over 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the verb, resource, and optional capabilities are all stated immediately and nothing is repeated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, and annotations cover the safety profile. What is missing is any routing between this tool and execute-query for ad-hoc versus table-scoped retrieval, which matters given the crowded sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, so the schema already documents skip, first, filters, and tableName, including the 1000-row maximum. The description names the three parameter families at a high level but adds no syntax, operator, or ordering details beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Retrieves data from a specific table') plus the three capability areas (filtering, pagination, ordering). However, it never distinguishes itself from the sibling execute-query, which appears to serve a similar data-retrieval purpose, so the agent must infer the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no exclusions, and no mention of the obvious alternative (execute-query) despite the sibling list containing a general query tool. The agent gets a description of what the tool does but nothing about when to prefer it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns all indexes for a table, including ordered columns, uniqueness, direction, and segment count.
| Name | Required | Description | Default |
|---|---|---|---|
| tableName | Yes | Name of the table whose relational metadata should be returned |
| Name | Required | Description |
|---|---|---|
| error | No | Failure information; present when success is false |
| result | No | The legacy JSON payload; present for completed operations and partial batches |
| success | Yes | False for tool failures, including partially failed batches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the description is not required to explain safety or side effects. It adds scope context (indexes metadata for a single table) but no operational details like pagination, ordering of results, or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence enumerates the returned content with zero filler. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a full output schema present, the description needn't detail return values, and it is adequate for a simple one-parameter read tool. The only minor gap is the absence of usage routing against sibling metadata tools, but nothing essential to correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a single parameter whose schema description already explains it returns relational metadata for the named table. The description does not add format, case-sensitivity, or qualification-syntax details beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Returns) and resource (all indexes for a table), and enumerates the returned fields (ordered columns, uniqueness, direction, segment count). This is clearly distinguishable from siblings like get-table-constraints or get-table-triggers without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (inspecting index structure for a given table) but offers no explicit when-to-use/when-not guidance or named alternatives. An agent can infer the context, but nothing routes it here versus get-table-constraints or analyze-missing-indexes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns only the triggers associated with a table, including source, description, sequence, type, and active state.
| Name | Required | Description | Default |
|---|---|---|---|
| tableName | Yes | Name of the table whose relational metadata should be returned |
| Name | Required | Description |
|---|---|---|
| error | No | Failure information; present when success is false |
| result | No | The legacy JSON payload; present for completed operations and partial batches |
| success | Yes | False for tool failures, including partially failed batches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, fully covering the safety profile for a read operation. The description adds no behavioral context beyond that (no ordering guarantees, no handling of a missing table), so it neither contradicts nor enriches the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the verb and scope, with no filler. The enumerated return fields are mildly redundant given the output schema, but the sentence is tight and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich annotation set, a fully documented single parameter, and an output schema, the description only needs to establish purpose and scope, which it does. The one residual gap is not explicitly routing the agent between this tool and the sibling list-triggers/describe-trigger.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter tableName has 100% schema description coverage, so the schema already documents it fully. The description adds no format or constraint detail beyond identifying the table scope, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (returns triggers for a table) and names the returned fields. The word "only" scopes it relative to the sibling list-triggers, but the differentiation is implicit rather than explicit. An agent can mostly tell it apart, though not with the certainty of a named alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the table-scoped nature suggests using this when you already know the table, versus list-triggers for a broad listing. No explicit when-to-use, prerequisites, or named alternatives are given, so the agent must infer the choice from the name and scope wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets detailed information about a specific tool
| Name | Required | Description | Default |
|---|---|---|---|
| toolName | Yes | Name of the tool to get help for |
| Name | Required | Description |
|---|---|---|
| error | No | Failure information; present when success is false |
| result | No | The legacy JSON payload; present for completed operations and partial batches |
| success | Yes | False for tool failures, including partially failed batches |
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 by structured data. The description adds nothing beyond this — no note on what 'detailed information' contains, nor whether an unknown toolName errors. It neither contradicts nor enriches 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with no wasted words. It is efficient, though its brevity borders on under-specification rather than optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and the tool is a simple read-only lookup. Still, the definition omits any routing context relative to list-available-tools or the describe-* family, leaving a gap for a tool whose main value is discovery.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage and a single, self-explanatory toolName parameter, the schema carries the full burden. The description adds no meaning beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource: it retrieves detailed information about a specific tool. However, it does not distinguish itself from siblings like list-available-tools or the many describe-* tools, leaving the agent to infer whether 'tool' means an MCP tool or a database object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this versus list-available-tools (which presumably lists tools) or why an agent would call it at all. No prerequisites, no exclusions, no alternative named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists native events (POST_EVENT) available in database triggers and procedures
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| error | No | Failure information; present when success is false |
| result | No | The legacy JSON payload; present for completed operations and partial batches |
| success | Yes | False for tool failures, including partially failed batches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and closed-world scope, so the safety profile is fully covered. The description's only added behavioral context is that the events are native POST_EVENT types relevant to triggers and procedures; it says nothing about whether any events are user-defined versus built-in.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler, which is well matched to a zero-parameter list tool. It is arguably under-specified rather than over-specified, but there is no wasted verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described. Still, for a discovery tool that feeds into subscribe_to_event, the description omits why an agent would list these events or how the result is used, leaving a gap in the overall workflow picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. Nothing in the description is needed to compensate, and nothing in it conflicts with the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Lists') and a specific resource ('native events (POST_EVENT)') plus its scope ('available in database triggers and procedures'). It is distinguishable from sibling list-* tools, though it never names an alternative such as subscribe_to_event or list-triggers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no mention of prerequisites, and no direction toward the closely related siblings subscribe_to_event / unsubscribe_from_event. The agent must infer the workflow entirely on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all tools available on the MCP server
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter by category (database, metadata) |
| Name | Required | Description |
|---|---|---|
| error | No | Failure information; present when success is false |
| result | No | The legacy JSON payload; present for completed operations and partial batches |
| success | Yes | False for tool failures, including partially failed batches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that - no scoping, no freshness/caching behavior, no note that the list is static or dynamic on the server.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with zero waste; the purpose is stated immediately. It is arguably thin rather than overly concise, but there is no padding or redundancy to penalize.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-required-parameter list tool with an output schema and full annotations, the definition is technically callable, but it omits the category-filter semantics and any sibling routing. Minimum viable, not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single category parameter is already documented with its allowed values (database, metadata). The description does not reference the filter at all, so baseline 3 applies - the schema carries the parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Lists) and resource (all tools available on the MCP server), so the agent immediately knows what it returns. It does not, however, distinguish itself from the related sibling get-tool-help, which is the natural alternative an agent might consider.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use, when-not-to-use, or alternative guidance is given. The description never mentions the category filter or when an agent would want it, and nothing routes the agent between this tool and get-tool-help or get-server-info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all functions in the database (UDFs and PSQL functions)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| error | No | Failure information; present when success is false |
| result | No | The legacy JSON payload; present for completed operations and partial batches |
| success | Yes | False for tool failures, including partially failed batches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds scope context (both UDFs and PSQL functions), which is mildly useful, but says nothing about ordering, pagination, or volume of results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the scope qualifier is placed immediately after the core verb+resource so nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return shape need not be described, and annotations cover safety; the description plus structured data is nearly complete. The only minor gap is the absence of guidance on how this relates to the many sibling list/describe tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4; there are no parameter semantics to clarify and the description does not need to compensate. No misleading parameter information is present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Lists) and resource (functions in the database), and the parenthetical '(UDFs and PSQL functions)' sharpens the scope to distinguish it from stored procedures/packages. It does not explicitly distinguish itself from the sibling describe-function or list-procedures, but the intent is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance: no mention of when to prefer this over list-procedures, list-packages, or describe-function for a specific function's details. Usage must be inferred entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all packages in the database (available in Firebird 3.0+)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| error | No | Failure information; present when success is false |
| result | No | The legacy JSON payload; present for completed operations and partial batches |
| success | Yes | False for tool failures, including partially failed batches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description's one added behavioral fact is the Firebird 3.0+ server-version requirement, which is genuinely useful (the call fails on older engines) but is a thin addition 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence that front-loads the action and appends the environment caveat. Nothing is wasted and nothing is buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an output schema present, the description need not explain return values, so the remaining burden is low. It covers the version prerequisite, but omits any routing to describe-package for detailed metadata, which is the only real gap for a listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to clarify. The description correctly implies an unfiltered, whole-database listing without claiming any parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Lists all packages'), so the agent knows exactly what the call returns. It does not explicitly differentiate itself from the nearby list-procedures/list-functions/describe-package siblings, but the verb+resource pairing is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The version qualifier ('available in Firebird 3.0+') implicitly tells the agent when the call is valid, but there is no explicit when-to-use guidance and no mention of describe-package as the sibling for detailed package metadata. Usage is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all stored procedures in the database with input and output parameter information
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| error | No | Failure information; present when success is false |
| result | No | The legacy JSON payload; present for completed operations and partial batches |
| success | Yes | False for tool failures, including partially failed batches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description's only added behavioral context is that output includes parameter information, which is modest value on top of the existing output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler or restatement of the tool name. It is appropriately sized for a zero-parameter listing tool, though it stops short of any additional scoping detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not explain return values, and with no parameters there are no inputs to document. The definition covers scope and output content adequately, though it could note whether results are filtered or scoped in any way.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. Schema coverage is also 100%, leaving no semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Lists all stored procedures') plus what the result contains (input and output parameter info). It does not explicitly differentiate itself from the sibling describe-procedure, which returns detail for a single procedure, but the 'all' scope makes the distinction reasonably inferable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The listing intent is implied by the name and description, but there is no explicit when-to-use guidance and no mention of the natural alternative (describe-procedure) for inspecting a single procedure in depth. A reader gets the gist without being routed between siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all user tables in the current Firebird database.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| error | No | Failure information; present when success is false |
| result | No | The legacy JSON payload; present for completed operations and partial batches |
| success | Yes | False for tool failures, including partially failed batches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds that only user tables are listed and that the scope is the current database, which is useful context beyond annotations, but it does not mention ordering, pagination, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no wasted words. It states the action, resource, and scope immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, rich annotations already covering safety and idempotency, and an output schema that handles return values, the description is complete for its complexity. It specifies the database scope and table type, which are the key details an agent needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. The description cannot add parameter meaning beyond the empty schema, and the schema fully covers the (nonexistent) parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Lists all user tables' and scopes it to 'the current Firebird database.' It clearly identifies the resource as user tables, distinguishing it from system tables, but does not explicitly differentiate itself from sibling tools like describe-table or get-table-data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no when-to-use guidance, no prerequisites, and no alternatives. It simply states what the tool does, leaving the agent to infer that it is used when a list of tables is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all database triggers with their associated table, trigger type, and status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| error | No | Failure information; present when success is false |
| result | No | The legacy JSON payload; present for completed operations and partial batches |
| success | Yes | False for tool failures, including partially failed batches |
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 fully covered by structured data. The description's added value is limited to stating the global scope and the fields returned (table, type, status), which overlaps with the output schema rather than disclosing new behavioral traits like pagination or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that states the resource, the scope, and the returned fields with no filler. Nothing could be removed without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description need not explain return values, and the read-only nature is covered by annotations. What is missing is routing context against the crowded sibling set (get-table-triggers, describe-trigger), which is the main gap for an agent selecting among trigger-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so per the rubric the baseline is 4. There are no parameter semantics to clarify, and the description correctly implies a no-argument, list-everything call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb (Lists) and resource (database triggers) plus the scope ('all'), which clearly distinguishes it from the table-scoped get-table-triggers sibling. However, it never names or contrasts with the closely related describe-trigger or get-table-triggers tools, so the agent must infer the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance and no mention of alternatives such as get-table-triggers (per-table scope) or describe-trigger (single-trigger detail). The word 'all' implicitly signals a broad listing, but the agent gets no stated rule for choosing this tool over its nearest siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a Firebird POST_EVENT listener; MCP resource subscription is also required for notifications
| Name | Required | Description | Default |
|---|---|---|---|
| eventName | Yes |
| Name | Required | Description |
|---|---|---|
| error | No | Failure information; present when success is false |
| result | No | The legacy JSON payload; present for completed operations and partial batches |
| success | Yes | False for tool failures, including partially failed batches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already supply readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds real behavioral context beyond them: notifications require a second, separate MCP resource subscription in addition to the Firebird listener, which an agent would otherwise miss.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence with the core action front-loaded and the prerequisite trailing after a semicolon. No wasted text, though the semicolon clause is slightly compressed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need no explanation, and the dual-subscription note is a useful addition. Still missing is how to discover valid event names and how to later undo the subscription via unsubscribe_from_event, leaving the agent to infer the full workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter (eventName) with 0% schema description coverage, and the description says nothing about it—neither format, source of valid values, nor constraints. With a single required param the description had an easy opportunity to add a pointer to list_available_events and did not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: 'Register a Firebird POST_EVENT listener'. This clearly separates it from unsubscribe_from_event and list_available_events. It is not explicitly differentiated from siblings in prose, keeping it just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage by naming a prerequisite ('MCP resource subscription is also required for notifications'), which is more than nothing. However, it never says when to subscribe vs. when to unsubscribe, nor points to list_available_events for valid event names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reports process health and runtime information; does not probe database connectivity
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| error | No | Failure information; present when success is false |
| result | No | The legacy JSON payload; present for completed operations and partial batches |
| success | Yes | False for tool failures, including partially failed batches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description's scope limitation (no database connectivity probing) adds genuine behavioral context about what the check actually covers, but it says nothing about cost, latency, or side effects beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the positive capability and appends the scope exclusion. No filler, no repetition of the title, and the constraint lands before an agent can mis-select the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not enumerate return fields, and with zero parameters there are no inputs to document. The only residual gap is that "runtime information" is left unelaborated, but the output schema carries that detail, making the definition adequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, which is the baseline-4 case. Schema coverage is 100% and there is nothing for the description to disambiguate or compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description pairs a specific verb ("Reports") with a concrete resource ("process health and runtime information"), so the agent knows it produces a diagnostic readout. The clarifying clause about not probing database connectivity further separates it from database-oriented siblings like get-database-info and verify-wire-encryption, though it doesn't name any sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The negative clause "does not probe database connectivity" is a useful when-not boundary, especially given the many DB-focused siblings an agent might otherwise confuse it with. However, there is no positive statement of when to call it and no alternative tool is named, so usage is only implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Release a Firebird event registration owned by this connection or HTTP application
| Name | Required | Description | Default |
|---|---|---|---|
| eventName | Yes |
| Name | Required | Description |
|---|---|---|
| error | No | Failure information; present when success is false |
| result | No | The legacy JSON payload; present for completed operations and partial batches |
| success | Yes | False for tool failures, including partially failed batches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (idempotentHint=true, destructiveHint=false, readOnlyHint=false), so the bar is lower. The description adds genuinely useful behavioral context beyond them: the operation only releases registrations owned by this connection or HTTP application, so it cannot affect other connections' subscriptions. It stops short of describing behavior when no matching registration exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the scoping constraint that matters most appears immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the annotations carry the safety profile. However, the sole parameter is undocumented in both schema and description, and there is no mention of failure behavior when the event is not currently subscribed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the single parameter eventName has no description in the schema. The description's phrase 'event registration' only weakly implies the parameter names an event; it gives no format, length, case-sensitivity, or cross-reference to list_available_events for valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Release') and resource ('a Firebird event registration'), and the 'owned by this connection or HTTP application' qualifier pins the exact scope. It reads as the clear inverse of the sibling subscribe_to_event, though it never names that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The scope phrase implies this is a teardown/cleanup operation for registrations this connection owns, but there is no explicit when-to-use, when-not, or pointer to subscribe_to_event / list_available_events as the companion tools. Usage is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reports wire-encryption configuration; does not verify negotiated encryption on an active database connection.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| error | No | Failure information; present when success is false |
| result | No | The legacy JSON payload; present for completed operations and partial batches |
| success | Yes | False for tool failures, including partially failed batches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds the genuinely useful behavioral boundary that this reports static configuration rather than runtime-negotiated encryption, preventing a common misinterpretation. It says nothing about permissions or cost, but nothing is contradicted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, front-loaded with what it reports and immediately followed by the scope caveat. No filler and nothing redundant with structured fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an output schema present, the description only needs to convey purpose and scope, which it does. The only minor gap is that it never hints at what the reported configuration contains, though the output schema likely covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so the schema carries no semantics for the description to add. Baseline of 4 applies for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: reporting wire-encryption configuration. It also pre-empts a likely confusion by stating it does not verify negotiated encryption on a live connection, which is stronger than a bare purpose statement. It does not, however, differentiate itself from other server/config-introspection siblings such as get-server-info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'does not verify negotiated encryption on an active database connection' clause implicitly tells the agent when this tool is the wrong choice, which is useful negative guidance. But it names no alternative tool and gives no positive condition for when to call this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.12.0analyze-missing-indexes3 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "__schema0": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "description": "Failure information; present when success is false",
+ "properties": {
+ "details": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "message",
+ "type"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "additionalProperties": false,
+ "description": "The legacy JSON payload; present for completed operations and partial batches",
+ "properties": {
+ "error": {
+ "type": "string"
+ },
+ "missingIndexes": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "recommendations": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "success": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "missingIndexes",
+ "recommendations",
+ "success"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "description": "False for tool failures, including partially failed batches",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+}analyze-query-performance6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / iterations / maximumAdded value: +9007199254740991Input schema / properties / params / items / anyOfRemoved value: -[
- {
- "anyOf": [
- {
- "type": [
- "string",
- "number"
- ]
- },
- {
- "type": "boolean"
- }
- ]
- },
- {
- "type": "null"
- }
-]Input schema / properties / params / items / typeAdded value: +[
+ "string",
+ "number",
+ "boolean",
+ "null"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "__schema0": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "description": "Failure information; present when success is false",
+ "properties": {
+ "details": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "message",
+ "type"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "additionalProperties": false,
+ "description": "The legacy JSON payload; present for completed operations and partial batches",
+ "properties": {
+ "analysis": {
+ "type": "string"
+ },
+ "averageTime": {
+ "type": "number"
+ },
+ "error": {
+ "type": "string"
+ },
+ "executionTimes": {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ "maxTime": {
+ "type": "number"
+ },
+ "minTime": {
+ "type": "number"
+ },
+ "query": {
+ "type": "string"
+ },
+ "rowCount": {
+ "type": "number"
+ },
+ "success": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "query",
+ "executionTimes",
+ "averageTime",
+ "minTime",
+ "maxTime",
+ "rowCount",
+ "success",
+ "analysis"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "description": "False for tool failures, including partially failed batches",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+}analyze-table-statistics3 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "__schema0": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "description": "Failure information; present when success is false",
+ "properties": {
+ "details": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "message",
+ "type"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "additionalProperties": false,
+ "description": "The legacy JSON payload; present for completed operations and partial batches",
+ "properties": {
+ "columnCount": {
+ "type": "number"
+ },
+ "columns": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "hasDefault": {
+ "type": "boolean"
+ },
+ "name": {
+ "type": "string"
+ },
+ "nullable": {
+ "type": "boolean"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "type",
+ "nullable",
+ "hasDefault"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "rowCount": {
+ "type": [
+ "number",
+ "string"
+ ]
+ },
+ "sampleSize": {
+ "type": "number"
+ },
+ "tableName": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "tableName",
+ "rowCount",
+ "columnCount",
+ "sampleSize",
+ "columns"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "description": "False for tool failures, including partially failed batches",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+}describe-batch-tables3 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "__schema0": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ },
+ "__schema1": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "description": "Failure information; present when success is false",
+ "properties": {
+ "details": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "message",
+ "type"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "description": "The legacy JSON payload; present for completed operations and partial batches",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "type": "string"
+ },
+ "errorType": {
+ "type": "string"
+ },
+ "schema": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "default_value": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "description": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "field_length": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "field_name": {
+ "type": "string"
+ },
+ "field_scale": {
+ "type": "number"
+ },
+ "field_type": {
+ "type": "string"
+ },
+ "nullable": {
+ "type": "boolean"
+ },
+ "primary_key": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "field_name",
+ "field_type",
+ "nullable",
+ "primary_key"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "tableName": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "tableName",
+ "schema"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "success": {
+ "description": "False for tool failures, including partially failed batches",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+}describe-function3 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "__schema0": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ },
+ "__schema1": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "description": "Failure information; present when success is false",
+ "properties": {
+ "details": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "message",
+ "type"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "additionalProperties": false,
+ "description": "The legacy JSON payload; present for completed operations and partial batches",
+ "properties": {
+ "description": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "entryPoint": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "moduleName": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "returnArgument": {
+ "type": "number"
+ },
+ "source": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "validBlr": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "name",
+ "returnArgument",
+ "validBlr"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "description": "False for tool failures, including partially failed batches",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+}describe-package3 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "__schema0": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ },
+ "__schema1": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "description": "Failure information; present when success is false",
+ "properties": {
+ "details": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "message",
+ "type"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "additionalProperties": false,
+ "description": "The legacy JSON payload; present for completed operations and partial batches",
+ "properties": {
+ "bodySource": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "description": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "headerSource": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "name": {
+ "type": "string"
+ },
+ "validBodyFlag": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "name",
+ "headerSource",
+ "validBodyFlag"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "description": "False for tool failures, including partially failed batches",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+}describe-procedure3 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "__schema0": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ },
+ "__schema1": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "description": "Failure information; present when success is false",
+ "properties": {
+ "details": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "message",
+ "type"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "additionalProperties": false,
+ "description": "The legacy JSON payload; present for completed operations and partial batches",
+ "properties": {
+ "description": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "inputParams": {
+ "type": "number"
+ },
+ "name": {
+ "type": "string"
+ },
+ "outputParams": {
+ "type": "number"
+ },
+ "source": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "validBlr": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "name",
+ "inputParams",
+ "outputParams",
+ "source",
+ "validBlr"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "description": "False for tool failures, including partially failed batches",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+}describe-table3 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "__schema0": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ },
+ "__schema1": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "description": "Failure information; present when success is false",
+ "properties": {
+ "details": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "message",
+ "type"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "additionalProperties": false,
+ "description": "The legacy JSON payload; present for completed operations and partial batches",
+ "properties": {
+ "schema": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "default_value": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "description": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "field_length": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "field_name": {
+ "type": "string"
+ },
+ "field_scale": {
+ "type": "number"
+ },
+ "field_type": {
+ "type": "string"
+ },
+ "nullable": {
+ "type": "boolean"
+ },
+ "primary_key": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "field_name",
+ "field_type",
+ "nullable",
+ "primary_key"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "schema"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "description": "False for tool failures, including partially failed batches",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+}describe-trigger3 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "__schema0": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ },
+ "__schema1": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "description": "Failure information; present when success is false",
+ "properties": {
+ "details": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "message",
+ "type"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "additionalProperties": false,
+ "description": "The legacy JSON payload; present for completed operations and partial batches",
+ "properties": {
+ "description": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "inactive": {
+ "type": "boolean"
+ },
+ "name": {
+ "type": "string"
+ },
+ "sequence": {
+ "type": "number"
+ },
+ "source": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "tableName": {
+ "type": "string"
+ },
+ "triggerType": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "tableName",
+ "triggerType",
+ "sequence",
+ "inactive",
+ "source"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "description": "False for tool failures, including partially failed batches",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+}echoexecute-batch-queries6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / queries / items / additionalPropertiesRemoved value: -falseInput schema / properties / queries / items / properties / params / items / anyOfRemoved value: -[
- {
- "anyOf": [
- {
- "type": [
- "string",
- "number"
- ]
- },
- {
- "type": "boolean"
- }
- ]
- },
- {
- "type": "null"
- }
-]Input schema / properties / queries / items / properties / params / items / typeAdded value: +[
+ "string",
+ "number",
+ "boolean",
+ "null"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "__schema0": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ },
+ "__schema1": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "description": "Failure information; present when success is false",
+ "properties": {
+ "details": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "message",
+ "type"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "additionalProperties": false,
+ "description": "The legacy JSON payload; present for completed operations and partial batches",
+ "properties": {
+ "results": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "data": {
+ "items": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "error": {
+ "type": "string"
+ },
+ "errorType": {
+ "type": "string"
+ },
+ "success": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "results"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "description": "False for tool failures, including partially failed batches",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+}execute-query5 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / params / items / anyOfRemoved value: -[
- {
- "anyOf": [
- {
- "type": [
- "string",
- "number"
- ]
- },
- {
- "type": "boolean"
- }
- ]
- },
- {
- "type": "null"
- }
-]Input schema / properties / params / items / typeAdded value: +[
+ "string",
+ "number",
+ "boolean",
+ "null"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "__schema0": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ },
+ "__schema1": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "description": "Failure information; present when success is false",
+ "properties": {
+ "details": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "message",
+ "type"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "additionalProperties": false,
+ "description": "The legacy JSON payload; present for completed operations and partial batches",
+ "properties": {
+ "rows": {
+ "items": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "rows"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "description": "False for tool failures, including partially failed batches",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+}get-database-info2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "__schema0": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "description": "Failure information; present when success is false",
+ "properties": {
+ "details": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "message",
+ "type"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "additionalProperties": false,
+ "description": "The legacy JSON payload; present for completed operations and partial batches",
+ "properties": {
+ "tables": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "totalTables": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "totalTables",
+ "tables"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "description": "False for tool failures, including partially failed batches",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+}get-execution-plan5 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / params / items / anyOfRemoved value: -[
- {
- "anyOf": [
- {
- "type": [
- "string",
- "number"
- ]
- },
- {
- "type": "boolean"
- }
- ]
- },
- {
- "type": "null"
- }
-]Input schema / properties / params / items / typeAdded value: +[
+ "string",
+ "number",
+ "boolean",
+ "null"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "__schema0": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ },
+ "__schema1": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "description": "Failure information; present when success is false",
+ "properties": {
+ "details": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "message",
+ "type"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "additionalProperties": false,
+ "description": "The legacy JSON payload; present for completed operations and partial batches",
+ "properties": {
+ "analysis": {
+ "type": "string"
+ },
+ "error": {
+ "type": "string"
+ },
+ "plan": {
+ "type": "string"
+ },
+ "planDetails": {
+ "items": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "type": "array"
+ },
+ "query": {
+ "type": "string"
+ },
+ "success": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "query",
+ "plan",
+ "planDetails",
+ "success",
+ "analysis"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "description": "False for tool failures, including partially failed batches",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+}get-field-descriptions3 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "__schema0": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ },
+ "__schema1": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "description": "Failure information; present when success is false",
+ "properties": {
+ "details": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "message",
+ "type"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "additionalProperties": false,
+ "description": "The legacy JSON payload; present for completed operations and partial batches",
+ "properties": {
+ "fieldDescriptions": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "description": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "description"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "fieldDescriptions"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "description": "False for tool failures, including partially failed batches",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+}get-server-info2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "__schema0": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "description": "Failure information; present when success is false",
+ "properties": {
+ "details": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "message",
+ "type"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "additionalProperties": false,
+ "description": "The legacy JSON payload; present for completed operations and partial batches",
+ "properties": {
+ "capabilities": {
+ "additionalProperties": false,
+ "properties": {
+ "features": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "tools": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "totalTools": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "tools",
+ "totalTools",
+ "features"
+ ],
+ "type": "object"
+ },
+ "description": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "runtime": {
+ "additionalProperties": false,
+ "properties": {
+ "memoryUsage": {
+ "additionalProperties": {
+ "type": "number"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "nodeVersion": {
+ "type": "string"
+ },
+ "platform": {
+ "type": "string"
+ },
+ "uptime": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "nodeVersion",
+ "platform",
+ "uptime",
+ "memoryUsage"
+ ],
+ "type": "object"
+ },
+ "version": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "version",
+ "description",
+ "capabilities",
+ "runtime"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "description": "False for tool failures, including partially failed batches",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+}get-table-constraints3 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "__schema0": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "description": "Failure information; present when success is false",
+ "properties": {
+ "details": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "message",
+ "type"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "additionalProperties": false,
+ "description": "The legacy JSON payload; present for completed operations and partial batches",
+ "properties": {
+ "constraints": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "checkSource": {
+ "type": "string"
+ },
+ "columns": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "indexName": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "references": {
+ "additionalProperties": false,
+ "properties": {
+ "columns": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "table": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "table",
+ "columns"
+ ],
+ "type": "object"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "columns"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "tableName": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "tableName",
+ "constraints"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "description": "False for tool failures, including partially failed batches",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+}get-table-data5 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / filters / items / additionalPropertiesRemoved value: -falseInput schema / properties / orderBy / items / additionalPropertiesRemoved value: -falseOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "__schema0": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ },
+ "__schema1": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "description": "Failure information; present when success is false",
+ "properties": {
+ "details": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "message",
+ "type"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "additionalProperties": false,
+ "description": "The legacy JSON payload; present for completed operations and partial batches",
+ "properties": {
+ "data": {
+ "items": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "rowCount": {
+ "type": "number"
+ },
+ "tableName": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "tableName",
+ "rowCount",
+ "data"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "description": "False for tool failures, including partially failed batches",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+}get-table-indexes3 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "__schema0": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "description": "Failure information; present when success is false",
+ "properties": {
+ "details": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "message",
+ "type"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "additionalProperties": false,
+ "description": "The legacy JSON payload; present for completed operations and partial batches",
+ "properties": {
+ "indexes": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "columns": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "isUnique": {
+ "type": "boolean"
+ },
+ "name": {
+ "type": "string"
+ },
+ "segmentCount": {
+ "type": "number"
+ },
+ "type": {
+ "enum": [
+ "ASCENDING",
+ "DESCENDING"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "isUnique",
+ "type",
+ "segmentCount",
+ "columns"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "tableName": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "tableName",
+ "indexes"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "description": "False for tool failures, including partially failed batches",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+}get-table-triggers3 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "__schema0": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "description": "Failure information; present when success is false",
+ "properties": {
+ "details": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "message",
+ "type"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "additionalProperties": false,
+ "description": "The legacy JSON payload; present for completed operations and partial batches",
+ "properties": {
+ "tableName": {
+ "type": "string"
+ },
+ "triggers": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "description": {
+ "type": "string"
+ },
+ "isActive": {
+ "type": "boolean"
+ },
+ "name": {
+ "type": "string"
+ },
+ "sequence": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "source": {
+ "type": "string"
+ },
+ "type": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "isActive",
+ "source"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "tableName",
+ "triggers"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "description": "False for tool failures, including partially failed batches",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+}get-tool-help3 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "__schema0": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "description": "Failure information; present when success is false",
+ "properties": {
+ "details": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "message",
+ "type"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "additionalProperties": false,
+ "description": "The legacy JSON payload; present for completed operations and partial batches",
+ "properties": {
+ "category": {
+ "enum": [
+ "database",
+ "metadata"
+ ],
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "inputSchema": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "usage": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "title",
+ "description",
+ "category",
+ "inputSchema",
+ "usage"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "description": "False for tool failures, including partially failed batches",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+}list-available-events2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "__schema0": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "description": "Failure information; present when success is false",
+ "properties": {
+ "details": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "message",
+ "type"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "description": "The legacy JSON payload; present for completed operations and partial batches",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "type"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "success": {
+ "description": "False for tool failures, including partially failed batches",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+}list-available-tools3 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "__schema0": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "description": "Failure information; present when success is false",
+ "properties": {
+ "details": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "message",
+ "type"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "description": "The legacy JSON payload; present for completed operations and partial batches",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "category": {
+ "enum": [
+ "database",
+ "metadata"
+ ],
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "title",
+ "description",
+ "category"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "success": {
+ "description": "False for tool failures, including partially failed batches",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+}list-functions2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "__schema0": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ },
+ "__schema1": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "description": "Failure information; present when success is false",
+ "properties": {
+ "details": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "message",
+ "type"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "additionalProperties": false,
+ "description": "The legacy JSON payload; present for completed operations and partial batches",
+ "properties": {
+ "functions": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "description": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "entryPoint": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "moduleName": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "returnArgument": {
+ "type": "number"
+ },
+ "source": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "validBlr": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "name",
+ "returnArgument",
+ "validBlr"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "totalFunctions": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "totalFunctions",
+ "functions"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "description": "False for tool failures, including partially failed batches",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+}list-packages2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "__schema0": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ },
+ "__schema1": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "description": "Failure information; present when success is false",
+ "properties": {
+ "details": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "message",
+ "type"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "additionalProperties": false,
+ "description": "The legacy JSON payload; present for completed operations and partial batches",
+ "properties": {
+ "packages": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "bodySource": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "description": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "headerSource": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "name": {
+ "type": "string"
+ },
+ "validBodyFlag": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "name",
+ "headerSource",
+ "validBodyFlag"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "totalPackages": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "totalPackages",
+ "packages"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "description": "False for tool failures, including partially failed batches",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+}list-procedures2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "__schema0": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ },
+ "__schema1": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "description": "Failure information; present when success is false",
+ "properties": {
+ "details": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "message",
+ "type"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "additionalProperties": false,
+ "description": "The legacy JSON payload; present for completed operations and partial batches",
+ "properties": {
+ "procedures": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "description": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "inputParams": {
+ "type": "number"
+ },
+ "name": {
+ "type": "string"
+ },
+ "outputParams": {
+ "type": "number"
+ },
+ "source": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "validBlr": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "name",
+ "inputParams",
+ "outputParams",
+ "source",
+ "validBlr"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "totalProcedures": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "totalProcedures",
+ "procedures"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "description": "False for tool failures, including partially failed batches",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+}list-tables2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "__schema0": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "description": "Failure information; present when success is false",
+ "properties": {
+ "details": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "message",
+ "type"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "additionalProperties": false,
+ "description": "The legacy JSON payload; present for completed operations and partial batches",
+ "properties": {
+ "tables": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "tables"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "description": "False for tool failures, including partially failed batches",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+}list-triggers2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "__schema0": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ },
+ "__schema1": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "description": "Failure information; present when success is false",
+ "properties": {
+ "details": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema1"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "message",
+ "type"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "additionalProperties": false,
+ "description": "The legacy JSON payload; present for completed operations and partial batches",
+ "properties": {
+ "totalTriggers": {
+ "type": "number"
+ },
+ "triggers": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "description": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "inactive": {
+ "type": "boolean"
+ },
+ "name": {
+ "type": "string"
+ },
+ "sequence": {
+ "type": "number"
+ },
+ "source": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "tableName": {
+ "type": "string"
+ },
+ "triggerType": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "tableName",
+ "triggerType",
+ "sequence",
+ "inactive",
+ "source"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "totalTriggers",
+ "triggers"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "description": "False for tool failures, including partially failed batches",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+}subscribe_to_event7 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / eventName / descriptionRemoved value: -"The name of the Firebird event to subscribe to (e.g. 'NEW_ORDER', 'CLIENT_UPDATED')"Input schema / properties / eventName / maxLengthAdded value: +127Input schema / properties / eventName / minLengthAdded value: +1Input schema / properties / eventName / patternAdded value: +"^[^\\u0000-\\u001f\\u007f]+$"Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "__schema0": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "description": "Failure information; present when success is false",
+ "properties": {
+ "details": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "message",
+ "type"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "additionalProperties": false,
+ "description": "The legacy JSON payload; present for completed operations and partial batches",
+ "properties": {
+ "eventName": {
+ "type": "string"
+ },
+ "registered": {
+ "type": "boolean"
+ },
+ "subscriptionAction": {
+ "enum": [
+ "open",
+ "close"
+ ],
+ "type": "string"
+ },
+ "uri": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "eventName",
+ "uri"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "description": "False for tool failures, including partially failed batches",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+}system-health-check2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "__schema0": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "description": "Failure information; present when success is false",
+ "properties": {
+ "details": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "message",
+ "type"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "additionalProperties": false,
+ "description": "The legacy JSON payload; present for completed operations and partial batches",
+ "properties": {
+ "environment": {
+ "additionalProperties": false,
+ "properties": {
+ "arch": {
+ "type": "string"
+ },
+ "nodeVersion": {
+ "type": "string"
+ },
+ "platform": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "nodeVersion",
+ "platform",
+ "arch"
+ ],
+ "type": "object"
+ },
+ "memory": {
+ "additionalProperties": false,
+ "properties": {
+ "external": {
+ "type": "number"
+ },
+ "total": {
+ "type": "number"
+ },
+ "used": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "used",
+ "total",
+ "external"
+ ],
+ "type": "object"
+ },
+ "status": {
+ "const": "healthy",
+ "type": "string"
+ },
+ "timestamp": {
+ "type": "string"
+ },
+ "tools": {
+ "additionalProperties": false,
+ "properties": {
+ "database": {
+ "type": "number"
+ },
+ "metadata": {
+ "type": "number"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "database",
+ "metadata",
+ "total"
+ ],
+ "type": "object"
+ },
+ "uptime": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "status",
+ "timestamp",
+ "uptime",
+ "memory",
+ "environment",
+ "tools"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "description": "False for tool failures, including partially failed batches",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+}unsubscribe_from_eventverify-wire-encryption2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "__schema0": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ]
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "description": "Failure information; present when success is false",
+ "properties": {
+ "details": {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "message",
+ "type"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "additionalProperties": false,
+ "description": "The legacy JSON payload; present for completed operations and partial batches",
+ "properties": {
+ "driverType": {
+ "enum": [
+ "native",
+ "pure-js"
+ ],
+ "type": "string"
+ },
+ "hasNativeDriver": {
+ "type": "boolean"
+ },
+ "recommendation": {
+ "type": "string"
+ },
+ "status": {
+ "const": "configuration-only",
+ "type": "string"
+ },
+ "verified": {
+ "const": false,
+ "type": "boolean"
+ },
+ "wireEncryptionEnabled": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "verified",
+ "status",
+ "hasNativeDriver",
+ "wireEncryptionEnabled",
+ "driverType",
+ "recommendation"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "description": "False for tool failures, including partially failed batches",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+}v2.10.0get-table-constraintsget-table-indexesget-table-triggersv2.9.3get-table-data12 fields changedInput schema / properties / filtersAdded value: +{
+ "description": "Structured filters; values are always parameterized",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "column": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "operator": {
+ "enum": [
+ "eq",
+ "ne",
+ "gt",
+ "gte",
+ "lt",
+ "lte",
+ "like",
+ "in",
+ "isNull",
+ "isNotNull"
+ ],
+ "type": "string"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ },
+ {
+ "items": {
+ "type": [
+ "string",
+ "number",
+ "boolean"
+ ]
+ },
+ "maxItems": 100,
+ "minItems": 1,
+ "type": "array"
+ }
+ ]
+ }
+ },
+ "required": [
+ "column",
+ "operator"
+ ],
+ "type": "object"
+ },
+ "maxItems": 20,
+ "type": "array"
+}Input schema / properties / first / defaultAdded value: +100Input schema / properties / first / descriptionPrevious value: -"Number of rows to retrieve (FIRST clause in Firebird)"New value: +"Number of rows to retrieve (maximum: 1000)"Input schema / properties / first / maximumAdded value: +1000Input schema / properties / orderBy / descriptionRemoved value: -"Optional ORDER BY clause (without the ORDER BY keyword)"Input schema / properties / orderBy / itemsAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "column": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "direction": {
+ "default": "ASC",
+ "enum": [
+ "ASC",
+ "DESC"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "column"
+ ],
+ "type": "object"
+}Input schema / properties / orderBy / maxItemsAdded value: +10Input schema / properties / orderBy / typePrevious value: -"string"New value: +"array"Input schema / properties / skip / defaultAdded value: +0Input schema / properties / skip / descriptionPrevious value: -"Number of rows to skip (SKIP clause in Firebird)"New value: +"Number of rows to skip"Input schema / properties / skip / maximumAdded value: +1000000Input schema / properties / whereRemoved value: -{
- "description": "Optional WHERE clause (without the WHERE keyword)",
- "type": "string"
-}v2.9.0describe-function1 field changedInput schema / properties / functionName / descriptionPrevious value: -"Nombre de la función a describir"New value: +"Name of the function to describe"describe-package1 field changedInput schema / properties / packageName / descriptionPrevious value: -"Nombre del paquete a describir"New value: +"Name of the package to describe"describe-procedure1 field changedInput schema / properties / procedureName / descriptionPrevious value: -"Nombre del procedimiento almacenado a describir"New value: +"Name of the stored procedure to describe"describe-trigger1 field changedInput schema / properties / triggerName / descriptionPrevious value: -"Nombre del trigger a describir"New value: +"Name of the trigger to describe"get-tool-help1 field changedInput schema / properties / toolName / descriptionPrevious value: -"Nombre de la herramienta sobre la que obtener ayuda"New value: +"Name of the tool to get help for"list-available-tools1 field changedInput schema / properties / category / descriptionPrevious value: -"Filtrar por categoría (database, metadata)"New value: +"Filter by category (database, metadata)"v2.8.1backup-databasedescribe-functiondescribe-packagedescribe-proceduredescribe-triggerlist-available-eventslist-functionslist-packageslist-procedureslist-triggersrestore-databasesubscribe_to_eventvalidate-databasev1.0.0analyze-table-statisticsget-database-infoget-server-info1 field changedInput schema / additionalPropertiesRemoved value: -falseget-table-datalist-tables1 field changedInput schema / additionalPropertiesRemoved value: -falsesystem-health-check1 field changedInput schema / additionalPropertiesRemoved value: -falseverify-wire-encryptionanalyze-missing-indexesanalyze-query-performancebackup-databasedescribe-batch-tablesdescribe-tableexecute-batch-queriesexecute-queryget-execution-planget-field-descriptionsget-server-infoget-tool-helplist-available-toolslist-tablesrestore-databasesystem-health-checkvalidate-databaseScored across 32 tools
Most tools have clearly distinct purposes (list vs describe vs analyze vs execute patterns). A few overlaps exist: get-table-triggers vs list-triggers, and the meta cluster (get-server-info, list-available-tools, get-tool-help) all describe server/tooling information, which could cause some misselection.
Mostly consistent kebab-case verb-noun (list-tables, describe-table, analyze-query-performance), which is readable and predictable. However, subscribe_to_event and unsubscribe_from_event use snake_case, breaking the otherwise uniform hyphenated convention.
32 tools is on the heavy side for a database server, though most map to genuine Firebird schema/query/event operations. The meta tools (echo, get-server-info, list-available-tools, get-tool-help, system-health-check) add overhead beyond the core database domain.
Strong coverage of introspection (tables, triggers, procedures, functions, packages, indexes, constraints, events) plus query execution, batching, and performance analysis. DDL/DML is only implicit via execute-query, and there are no dedicated create/alter/drop tools, but execute-query covers those workflows.
Text-to-SQL MCP server: read-only queries on PostgreSQL, MySQL and SQL Server with your real schema
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
GibsonAI MCP server: manage your databases with natural language
