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

With no annotations, the description carries the full burden and does well: it discloses that it issues a SELECT against DirectDb and a GET against Service Layer, making clear this is a non-mutating probe, and that the two checks run independently. It does not state failure semantics (e.g., whether one failed connection causes an error or a partial report).

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?

Four short sentences, front-loaded with the purpose, followed by mechanism, then call mechanics and output. Every sentence adds information and none 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?

No output schema exists, so the description must hint at returns; 'Reports status for both connections' covers the shape adequately for a simple health check. It is complete enough to invoke correctly, with only the exact status format and failure behavior left unspecified.

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?

Zero parameters, so the baseline is 4. The description explicitly confirms 'No parameters required', which matches the empty input schema and removes any ambiguity for the agent.

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 (check/ping) and two specific resources (DirectDb, Service Layer), and states the exact mechanism used for each. It implicitly distinguishes itself from siblings like connect_database and execute_sql by being a status probe rather than an action, though it never names an alternative 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 explains what happens but not when to prefer this over connect_database or execute_sql, nor any precondition or exclusion. The only usage-adjacent statement is 'No parameters required', which is a call mechanic, not 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?

With no annotations, the description carries the full burden and does so well: it discloses that stale/non-matching sides are disconnected before replacement, that a healthy matching side stays active, that a partial single-side connection persists until retried, and that failed logins are tracked with lockout warnings. It omits auth prerequisites and what the tool returns, but the mutation semantics are unusually well spelled out.

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, then progressively narrower detail on matching, profile composition, and switch behavior. Reasonably tight for the number of behaviors disclosed; the 'Available profiles:' block is dynamic state rather than prose, and no sentence is pure 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 connection-switching tool with no annotations and no output schema, the description covers the important behaviors: search resolution, dual-side profiles, disconnection order, partial-connect outcomes, and lockout risk. Only the response shape after a successful switch is left 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 coverage is 100% and the schema already documents ID-or-name lookup and the 'list' keyword, so the baseline is 3. The description adds real meaning beyond that: matching is case-insensitive and partial matches are accepted only when they resolve to a single profile, which materially changes how an agent should format the query.

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: 'Switch the active database and Service Layer connection to a different SAP Business One environment.' None of the siblings (execute_service_layer, execute_sql, check_connection, get_schema_info, execute_service_layer_write*) perform connection switching, so the agent can separate it by scope 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?

Gives operational guidance for the 'list' query and for retrying a failed side, which is useful invocation context. However, it never states when to reach for this tool versus check_connection or the execute_* siblings, nor any explicit exclusion, so usage remains implied rather than directed.

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 well: it discloses the read-only nature, the profile-driven authorization gate, and where to inspect that gate (connect_database prints slAllowedMethods). It stops short of describing error responses or pagination behavior, which for a remote HTTP-style call the agent may still need.

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 with no filler; the core operation comes first, followed by the routing and denial rules. Every clause earns its place by adding a routing or constraint fact.

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 permission-gated remote call with no output schema, the description supplies the operation, the alternative, the authorization precondition, and the blocked endpoints, which is nearly everything needed. It omits only what a successful/error response looks like, which an agent might want before composing follow-up calls.

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 baseline is 3, but the description adds genuine constraint information about the url parameter: query options are accepted while absolute URLs, Login/Logout, and $batch are rejected. That meaning is not derivable from the schema description alone, which only says the endpoint is relative.

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 ('Execute a read-only OData GET against ... SAP Business One Service Layer') and immediately names the sibling that handles the complementary operation, execute_service_layer_write. An agent can distinguish this from every sibling 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?

Explicitly routes writes elsewhere ('Writes go through execute_service_layer_write'), states the exact condition under which the call is denied (slAllowedMethods omitting GET), and enumerates what is permitted (query options) versus denied (absolute URLs, Login/Logout, $batch). Both when-to-use and when-not are covered.

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 exist, so the description carries the full burden and does so: it warns these are real database writes, describes the exact denial condition for method/database mismatch, explains the three approval paths and which clients honour them, and enumerates denied endpoint shapes (query options, navigation, $batch, Login/Logout). This is far beyond what the schema conveys.

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 dense paragraphs, front-loaded with the verb and the write warning, then gating rules, then endpoint restrictions. Almost every sentence carries a constraint, though the approval-mode enumeration is long enough that a bulleted form would scan faster.

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 high-risk, four-parameter mutation tool with no annotations and no output schema, the description covers permissions, database matching, approval routing, dry-run and global kill switches, and accepted endpoint shapes. The only omission is error/response semantics, which is minor for a write operation.

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 baseline is 3, but the description adds real constraints the schema does not: method must be in the profile's slAllowedMethods, database must equal the connected Service Layer database exactly, and PATCH/DELETE accept only one keyed entity endpoint while POST accepts a set, operation, or single action. Body optionality is already covered by the schema, so it is not a full 5.

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 (execute) and resource (guarded OData write: PATCH/POST/DELETE against the SAP B1 Service Layer) and immediately scopes it as real company-database writes. It is clearly distinguishable from the read-oriented execute_service_layer sibling and from execute_service_layer_write_unattended, which it names directly.

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?

Explicitly says when writes are permitted (verb in slAllowedMethods, database must match connect_database exactly), how approval behaves per slWriteApproval mode, and when to prefer execute_service_layer_write_unattended over this tool. It also names MCP_DRY_RUN and MCP_SL_WRITES_ENABLED=false as global gates, leaving nothing 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, and it does: it warns these are real writes to the company database, states the denial condition, discloses that dry-run previews apply, and that an env flag can disable the tool entirely. It also reiterates the inherited guard rules (database must match, verb must be in slAllowedMethods).

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 tool's distinguishing property (no approval) before the denial condition and inherited rules. Both paragraphs earn their place, though the second paragraph is dense and could be tightened slightly.

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 mutation tool with no annotations and no output schema, the description covers the safety-critical facts an agent needs: approval gating, denial behavior, dry-run and feature-flag effects, and the inherited endpoint/verb constraints. 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 coverage is 100%, so the baseline is 3, but the description adds real semantics beyond the schema: database must equal the connected Service Layer database and the verb must also be permitted by the profile's slAllowedMethods. It does not add syntax or body-shape detail, but the constraint context is valuable.

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 (execute a guarded OData write) with the exact allowed methods (PATCH, POST, DELETE) and scope (no approval), and explicitly names the sibling it is not: use execute_service_layer_write when approval doesn't apply. An agent can distinguish it from the approval-gated sibling without opening either 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 an explicit gating condition — denied unless the connected profile's slWriteApproval is "none" (a value printed by connect_database) — and names the alternative tool to use otherwise. It also clarifies the environment conditions (MCP_DRY_RUN previews, MCP_SL_WRITES_ENABLED=false disables it).

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: server-side read-only enforcement, an enumerated block list (INSERT/UPDATE/DELETE/DROP, EXEC/CALL, CREATE/ALTER, OPENQUERY pass-through), and that there is no confirmation bypass. It also notes the reason writes are excluded (human review and transaction control), which is behaviorally meaningful.

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 purpose, then clearly sectioned with IMPORTANT / READ-ONLY / Rules headings that make it scannable. The read-only restriction is stated two or three times (prose, rule list, schema), which is mild redundancy, but the length is justified by the safety-critical 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?

Given no annotations and no output schema, the description is impressively complete on safety and routing. It is silent on operational limits that matter for a SQL executor (row caps, timeouts, pagination, or what the result set looks like), which is the only notable 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?

One parameter with 100% schema coverage, so the schema already documents 'query'. The description only restates that it is SELECT-only, which duplicates the schema's own description; 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 precise verb and resource ('Execute a raw SQL statement against the currently connected database'), which is unambiguous. It does not, however, name or contrast itself against the sibling tools execute_service_layer / execute_service_layer_write, so an agent must infer the raw-SQL-vs-service-layer 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?

Explicitly states the precondition (the user MUST have named the target database, otherwise ask first), the allowed case (SELECT only), and the exclusion with a concrete alternative (writes should be handed to the user to run in HANA Studio / DBeaver / hdbsql). Both when-to-use and when-not-to-use are covered with a redirect.

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 — and it does disclose the key trait ('Read-only') plus the scope constraint ('currently connected database') and a safety precondition about not assuming the target DB. It omits any statement about permissions, result volume, or pagination limits.

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?

Per-objectType filter guidance is front-loaded and every sentence relates to correct invocation. The IMPORTANT block is slightly repetitive ('ASK them first' followed by 'Do NOT assume'), which costs a little tightness.

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

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

For a simple two-parameter read tool with no output schema, the description covers purpose, safety, parameter behavior, and the critical database-confirmation precondition. The only gap is that it says nothing about return shape, though metadata output is largely predictable.

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 description's filter guidance (table name required for columns, optional LIKE pattern otherwise) essentially restates what the schema already declares for both properties. It adds salience for the conditional requirement but no new semantics, 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 — retrieving metadata about tables, columns, or procedures — and scopes it to the currently connected database. This clearly separates it from the execute_sql / execute_service_layer siblings, which run statements rather than describe schema.

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

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

Gives explicit usage context ('explore the schema before writing queries') and a hard precondition (confirm the user's target database, ask if unstated). It also spells out per-objectType filter behavior. It stops short of naming an alternative tool for the query-writing task, so it does not reach the full when/when-not/alternatives bar.

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