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

No annotations are provided, so the description carries the full burden. It implies an upsert ('cadastra ou atualiza') but never discloses that credentials (user/password, default 'masterkey') are persisted, that save_to_file defaults to true, or whether an existing entry is overwritten, merged, or requires elevated permission.

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 tight sentences, front-loaded with the core action before the optional association features. Nothing is padded, though the second sentence could have been spent on parameter meaning instead of a single example.

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 12-parameter mutation tool with zero annotations, no output schema, and 0% schema coverage, the description leaves most call-relevant behavior and parameter meaning undocumented. An agent cannot confidently construct a correct call from this.

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% across 12 parameters, yet the description only touches two of them (projects and tags) and gives an example value for projects. Host, port, user, password, charset, alias, database, save_to_file, set_as_default, and description remain completely unexplained in both places.

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: registers or updates a database in the catalog, with the global/local distinction and the ability to bind projects and tags. It clearly separates itself from list/use siblings, though it does not explicitly distinguish itself from fb_create_config, the closest 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 implied by the mention of 'global ou local' scoping and the projects/tags association example, but there is no explicit when-to-use vs fb_create_config or fb_use_database, and no prerequisites (e.g. server reachability) are stated.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the default write target (~/.firebird-mcp.json) and that projects/tags can be associated, but says nothing about overwriting existing entries, required permissions, credentials handling, or reversibility of a global-catalog write.

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 tightly written sentences with no filler, and the core action plus default destination are front-loaded. It is efficient, though it errs on the side of being too sparse for an 11-parameter tool.

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

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

For a config-writing tool with 11 parameters, no annotations, and no output schema, the description is far too thin. The agent lacks any explanation of most parameters and of the side effects of writing to a global config file.

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 0% across 11 parameters, so the description must compensate. It only elaborates on projects (with an example) and tags, leaving host, port, user, alias, charset, filepath, password, and description entirely unexplained in either place.

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?

Clearly states a specific verb+resource: creates and saves a new configuration file, naming the default target (~/.firebird-mcp.json). However, it does not distinguish itself from sibling fb_configure_database, which plausibly also touches configuration, leaving ambiguity about which to pick.

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 or prerequisites are given. It never explains when to create a config versus calling fb_configure_database or fb_reload_config, so the agent must infer intent 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.

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

With no annotations, the description carries the full burden. It discloses the data source (MON$ tables) and enumerates the diagnostic outputs, implying a read-only operation, but never states that it is side-effect free or whether special privileges are needed. The multi-database handling note adds real behavioral context.

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 short lead line followed by a scannable bullet list of what is diagnosed, then a procedural caveat. Front-loaded and mostly waste-free, though the trailing guidance sentence could be tightened.

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 diagnostic tool with no annotations, no output schema, and one undocumented parameter, the description does a decent job of explaining what is checked, but it leaves the sole parameter and the read-only nature unspecified. Adequate but with clear 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?

The single parameter db_alias has 0% schema coverage and the description never defines it (type, format, or meaning). The closest is the procedural note about asking the user when multiple databases exist, which gestures at database selection but does not explain the parameter itself.

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 ("Diagnostica") plus a precise resource (Firebird database integrity/telemetry via the MON$ system tables). The bullet list names exactly what is inspected (engine/ODS version, page size, sweep interval, OAT gap, active connections/transactions/statements), which clearly separates it from generic siblings like fb_query or fb_inspect_table.

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 via what it reports (diagnostics/health check) but never states when to prefer it over fb_query or fb_inspect_table. It does add one useful precondition rule — ask the user when multiple databases exist and none is active — which is more than a bare tool.

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

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

With no annotations, the description carries the full burden and does so richly: it discloses exclusive metadata locks, dependency effects, DROP irreversibility, commit semantics, and a double-confirmation protocol tied to the confirmed flag. This is exactly the behavioral context an agent needs for a destructive operation.

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?

Front-loaded with the purpose followed by the safety rule, and every step earns its place for a dangerous tool. Slightly verbose and repetitive in the safety section, but the structure is logical.

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 DDL mutation tool with no annotations and no output schema, the description covers safety, side effects, and the confirmation flow well. It does not describe the response/return shape or error behavior, though no output schema exists to offload 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?

Schema description coverage is 0%, so the description must compensate. It explains the confirmed=True workflow explicitly and implies db_alias selection via the multi-database guidance; the ddl parameter is self-evident from the purpose. Minor gap: db_alias is not fully spelled out.

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 (executa) and resource (comandos estruturais DDL no Firebird), enumerating the exact operations (CREATE, ALTER, DROP, RECREATE) and noting the explicit commit. It clearly distinguishes itself from data-manipulation siblings like fb_execute_dml and fb_query.

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?

Provides an explicit mandatory workflow: enumerate the exact DDL, explain structural impact, detail locks/dependencies/irreversibility, request confirmation, and only then re-invoke with confirmed=True. It also dictates behavior when no database is active. The 'never without express authorization' clause is a clear when/when-not rule.

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

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

With no annotations present, the description carries the full burden and does so well: it declares the destructive nature of DML, mandates double confirmation via `confirmed=True`, and tells the agent to disclose reversibility, lock risk, and potential data loss. It stops short of describing transaction/commit behavior or the shape of the response.

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?

Core purpose is front-loaded in one line, followed by a clearly numbered safety checklist that suits a destructive tool. Length is proportionate to risk, though the repeated confirmation warning ('NUNCA deve executar... sem autorização expressa' restated in the steps) is slightly 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?

For a destructive, annotation-free, 3-parameter tool with no output schema, the description supplies the safety workflow, the confirmation gate, and database-selection handling. The main remaining gap is transactional semantics — whether the statement commits, and how to roll back.

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

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

Schema description coverage is 0%, so the description must compensate, and it explains two of three parameters meaningfully: the purpose of `confirmed=True` (only after explicit user authorization) and how to resolve `db_alias` when multiple databases exist. The `sql` parameter is self-evident from its name but gets no format guidance.

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 — executing DML commands — and enumerates the exact statement classes (INSERT, UPDATE, DELETE, EXECUTE PROCEDURE), which cleanly separates it from the read-only fb_query and the schema-changing fb_execute_ddl siblings. An agent knows immediately what class of operation this tool performs.

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?

Provides an explicit, ordered when-to-use protocol (present SQL, explain effect, detail impact, request confirmation) plus the edge case of multiple databases with no active session. It does not name fb_query or fb_execute_ddl as the alternatives for reads or DDL, so routing between siblings is left partly to inference.

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

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

No annotations are provided, so the description carries the full burden. It discloses what the tool analyzes and returns (plan, NATURAL SCAN/SORT findings, recommendations), which is genuinely informative, but it never states whether the SQL is actually executed or only compiled, nor any permission/side-effect implications for a potentially mutating statement.

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?

Three short sentences that front-load the core action (compile + extract plan) before the analysis and the ambiguity-handling instruction. No filler, though the final conditional could be integrated more tightly.

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 annotations, no output schema, and 0% parameter coverage, the description should work harder. It adequately conveys purpose and the main output categories, but omits whether the query executes, the interpretation of db_alias, and any input format expectations, leaving real gaps for an agent to fill by inference.

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 neither parameter is documented in the schema. The description only indirectly gestures at db_alias via the 'multiple databases / no active database' instruction, and says nothing about the required sql parameter's form or constraints, leaving the schema's gaps unfilled.

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: it compiles a SQL query in Firebird and extracts the compiled execution plan (PLAN), then analyzes NATURAL SCAN and SORT operations and gives indexing/rewrite recommendations. This clearly separates it from siblings like fb_query (execution) and fb_inspect_table (schema inspection).

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 gives one concrete conditional instruction (ask the user when multiple databases exist and none is active in the session), which is useful context. However, it never states when to choose this over fb_query or fb_inspect_table, nor any prerequisite for the SQL input; usage is only implied by the analysis-oriented purpose.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the depth and shape of what is read and the session/database precondition, but never states that the operation is read-only and side-effect free, nor any permission requirement. That leaves a meaningful gap for a no-annotation tool.

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?

Front-loaded with the verb and purpose, then a tight bullet list of inspected artifacts plus a one-line operational caveat. Efficient and scannable, with no filler; the bullets could have been slightly condensed but 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?

With no output schema and no annotations, the description must convey the return payload, and it does: columns/types, keys, and index statistics. What an agent needs in order to call it correctly is mostly present; only the read-only nature and parameter contract remain implicit.

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

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

Schema description coverage is 0%, so the schema offers no parameter meaning. The description partially compensates by implying db_alias selects among project databases and that the session-active database acts as the default, but it never explains the db_alias/table_name contract directly. With only two self-evident-by-name parameters this is borderline adequate.

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 (inspects) and resource (table structure) and then enumerates exactly what it returns: columns with exact types/domains/nullability, PK/FK, and indexes with ordering and real selectivity. This clearly separates it from siblings like fb_list_tables, which only enumerate names.

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?

Gives an explicit situational rule: if multiple databases exist and none is active in the session, ask the user before proceeding. It does not name a sibling alternative (e.g., fb_list_tables for names only) or state when not to use it, so it stops short of a 5.

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

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

With no annotations, the description carries the full behavioral burden. It does add genuine context — reads from a global catalog or local file, resolves the active project, and signals when user confirmation may be required for multi-database projects — but says nothing about whether the call mutates state, permission needs, or error 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 sentences, front-loaded with the core action and source locations, then the secondary behavior about confirmation. No filler, though the second sentence is slightly roundabout in phrasing.

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 one-parameter read tool with no annotations and no output schema, the description conveys the return concept (list of configured databases, which belong to the active project, and a confirmation flag). The unresolved parameter documentation is the main gap.

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

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

Schema description coverage is 0% and the single parameter (project_filter) is never mentioned in the description. The passing reference to 'projeto ativo' hints at project scoping but does not explain what project_filter accepts or how it interacts with the active project, so the parameter remains effectively undocumented.

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 ('Lista todos os bancos de dados Firebird') and names the configuration sources (~/.firebird-mcp.json or local file), so the agent knows exactly what is returned. It does not explicitly contrast itself with siblings like fb_use_database or fb_create_config, so it stops short of a 5.

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

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

The description implies a discovery/context-checking role ('identificando os bancos correspondentes ao projeto ativo') but never states when to call this versus fb_create_config, fb_use_database, or fb_configure_database. No prerequisites, ordering, or exclusions are given, leaving the agent to 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.

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

With no annotations, the description carries the full behavioral burden. It conveys that this is a read/list operation and discloses the session-database default plus an ambiguity protocol (ask the user when multiple DBs exist and none is active). It omits permission/prerequisite requirements and any hint about result shape, which matters since there is no 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?

Two short sentences, front-loaded with the core action and followed by the one necessary caveat about database selection. No filler; only the missing alias-discovery detail keeps it from being maximally tight.

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 single-optional-parameter list tool with no annotations or output schema, the description covers what is listed, the parameter's meaning and default, and the multi-database ambiguity case. Only the return format and alias discovery are left implicit, which is acceptable 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 coverage is 0%, so the description must compensate, and it largely does: "no banco especificado (ou ativo na sessão)" explains that db_alias selects a database and that the parameter is optional because the session-active database is used as the fallback. It stops short of stating the alias format or how to discover valid aliases.

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 ("Lista") and a precise resource ("Generators / Sequences de usuário"), scoping it to a database. This clearly separates it from siblings such as fb_list_tables, fb_list_views and fb_list_procedures, which target different object types.

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 gives real usage context: list generators in the specified database or the session-active one, and ask the user when several databases exist and none is active. It does not name alternative tools (e.g., fb_list_databases first, or fb_use_database to set the active DB), so it stops short of full routing guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the session-active fallback and the multi-database disambiguation behavior, but says nothing about read-only nature, permissions, or result shape for a read/list operation.

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 tight sentences, front-loaded with the core action followed by the one conditional caveat. Nothing is wasted and no filler is present.

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 one-optional-parameter list tool with no output schema, the description covers the main ambiguity an agent faces (which database). It is essentially complete, missing only minor read-only confirmation.

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 0% and the single db_alias parameter is undocumented in the schema. The description compensates partially by clarifying the parameter is optional and defaults to the session-active database, but adds no format or accepted-value detail for the alias itself.

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 ('Lista') and resource ('Stored Procedures') with a stated scope (specified DB or session-active DB), which is enough to separate it from fb_list_tables, fb_list_views and fb_list_generators. It does not explicitly name those siblings, so differentiation is implicit rather than spelled out.

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?

Gives real usage context: when the DB is ambiguous and none is active, the agent is told to ask the user first. That is actionable routing guidance, though it never names an alternative sibling or a when-not-to-use condition.

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

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

With no annotations, the description carries the full burden. It does disclose a real behavioral rule (filter out system tables, and prompt the user instead of guessing when the target database is ambiguous), which is useful. However, it says nothing about output shape, ordering, pagination, or whether a live connection is required, leaving notable gaps for an annotation-free tool.

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, correctly front-loaded with the core operation followed by the ambiguity-handling rule. No filler or repetition of schema content.

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-optional-parameter listing tool with no output schema and no annotations, the description covers what it returns, the scoping rule, the session fallback, and the ambiguity prompt. Only the return format and how to obtain a valid db_alias remain unstated, which is a minor gap.

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

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

Schema description coverage is 0% for the single optional db_alias parameter. The description partly compensates by explaining the semantics: it names the database or falls back to the session-active one. It does not say what form an alias takes or that it comes from fb_list_databases, so the compensation is only partial.

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 (list user tables) plus an explicit scope qualifier that excludes system tables, which immediately separates it from sibling listing tools like fb_list_views, fb_list_procedures, and fb_list_generators. An agent can tell exactly what this returns without opening the 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?

Gives a clear conditional rule: when multiple databases exist and none is session-active, ask the user before proceeding. It encodes the fallback (use whatever database is active in the session) rather than naming rival tools, so the 'when' is covered but no explicit alternative/instead-of routing is provided.

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

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

With no annotations, the description carries the full burden. It discloses the session/database-resolution behavior and the interactive prompt fallback, which is useful. But it does not state that this is a read-only listing operation, nor anything about result format, 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?

Two short sentences with the core behavior front-loaded and the edge-case instruction second. No filler; every clause carries 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?

For a simple read-only listing tool with one optional parameter and no output schema, the description covers the key ambiguity (which database) and the interactive fallback. Minor gaps remain on whether the result is a plain name list and whether an active session is required.

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 db_alias is undocumented in the schema, so the description must compensate. It does: "do banco especificado (ou ativo na sessão)" explains both the parameter's meaning and the default fallback when it is omitted.

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 ("Lista todas as views de usuário") scoped to a database, which cleanly separates it from siblings like fb_list_tables and fb_list_procedures by resource type. It is clear what the tool does, though it does not explicitly name the sibling alternatives.

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

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

It gives a concrete conditional rule: when multiple databases exist and none is active in the session, prompt the user first. However, it does not state when to prefer this tool over adjacent listing tools or what prerequisites exist, so usage is only implied beyond that one edge case.

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

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

With no annotations, the description carries the full burden and does real work: enforced row limit of 1-1000, rejection of data-alteration statements, and immediate commit that ends the transaction. It omits error surface, connection/permission requirements, and what happens to the row limit vs. the `limit` parameter when they conflict.

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?

Three short sentences, front-loaded with the operation and its safety bound, then the transaction semantics, then the one conditional instruction. No filler or repetition.

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?

No output schema and no annotations, so the description must cover behavior end to end; it handles safety, limit bounds, transaction outcome, and the ambiguous-database case. Missing details are the shape of returned rows and behavior when the query hits the row cap.

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% on 3 parameters, so the description should compensate more than it does. It does add real meaning for `limit` (the 1-1000 safe bound vs. the schema's bare default of 50) and hints at `db_alias` through the multi-database advice, but it never describes the `sql` argument's accepted form or the alias resolution rules.

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 ('Executa consulta SELECT de leitura no Firebird') plus the enforced scope (read-only, safe row limit). This cleanly separates it from the mutating siblings fb_execute_dml and fb_execute_ddl 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?

Gives a concrete routing condition: if multiple databases exist and none is active in the session, ask the user. It also implies read-only usage by stating alteration commands are rejected, but it never explicitly names fb_execute_dml/fb_execute_ddl as the alternatives for writes.

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

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

No annotations are provided, so the description carries the full burden. It says where the config is read from but not what happens on reload (does it overwrite in-memory state, replace the connection pool, fail on malformed files, take effect immediately?), nor does it state the precedence between global and local sources despite listing both.

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 no filler. Slightly under-specified rather than overly padded, 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?

With no annotations, no output schema, and an undocumented parameter, the description should describe the reload's effect and result. It leaves the agent without knowing what changes after the call or how to detect success.

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% for the single 'config_path' parameter, so the description must compensate. It hints at the source choices ('Catálogo Central Global' vs 'arquivo local do projeto') but never connects them to config_path, its expected format, or what a null default implies.

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

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

States a specific verb ('Recarrega') and resource ('configuração de bancos') and names two distinct sources (global catalog ~/.firebird-mcp.json or project-local file), which is clearer than a bare reload tool. It does not, however, distinguish itself from siblings like fb_create_config or fb_use_database, so an agent must infer the reload-vs-create-vs-select 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?

There is no explicit when-to-use guidance, no mention of prerequisites (e.g. after editing the config file), and no named alternative among the siblings. Usage context is only weaky implied by 'a partir do Catálogo Central Global'.

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

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

With no annotations, the description carries the full burden and it does disclose two meaningful traits: the change is session-wide (all subsequent calls without 'db_alias' use it) and the lookup is fuzzy (exact, case-insensitive, substring on alias or tag). It omits failure behavior when no or multiple matches are found, which keeps it from a 5.

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?

Three short sentences, each earning its place: purpose first, matching behavior second, downstream effect third. No redundancy or filler.

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

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

For a one-parameter session-state tool with no output schema and no annotations, the description covers purpose, matching rules, and the persistent effect on later calls. Only ambiguity/error handling (no match, multiple matches) is left unaddressed.

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

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

Schema coverage is 0% and the single 'alias' parameter is titled only. The description compensates well by explaining the matching semantics (exact name, case-insensitive, substring against alias or tag, with a concrete 'auditoria' -> 'erp_auditoria' example), which an agent needs to pass the right value.

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 action (set the active database for the session) on a specific resource (the configured catalog), and the scope ('sessão') distinguishes it from sibling tools like fb_list_databases or fb_create_config. An agent can tell immediately this is a state-setting tool, not a listing or querying tool.

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 clearly frames when to use it: to define the active database so that later calls omitting 'db_alias' inherit it. It does not explicitly name or exclude alternatives (e.g., passing db_alias per call instead of setting state), so 4 rather than 5.

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