Bramvia: Business Central & Dynamics NAV

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the description doesn't need to establish safety. It does add real value by disclosing the return shape (0-100 score, risk drivers, one of three recommendation bands) since there is no output schema. However, it says nothing about how a 'short description' is mapped to parameters, whether omitted optional inputs default or lower confidence, or whether the score is deterministic or advisory.

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, no waste, with the core action front-loaded and the output contract following immediately. Nothing should be removed.

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 seven inputs, no output schema, and no annotations covering results, the description does the necessary work of explaining what comes back. It falls short only on the interaction between the single required parameter and the six optional ones, which an agent would need in order to decide how much detail to supply.

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 every parameter including all enum values is already documented in the schema; baseline 3 applies. The description only gestures at 'a short description of its situation' and adds no per-parameter meaning, nor does it clarify that system is the sole required input while the other six are optional enrichment.

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: 'Score the structural risk of a company's current ERP from a short description of its situation'. This distinguishes it from the estimation siblings (estimate_migration, estimate_bridge_to_cloud_savings), though it never names 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?

Usage is implied by 'from a short description of its situation' — the agent infers it should call this when it has qualitative ERP context and wants a risk verdict. There is no explicit when-not guidance, no mention of alternatives like estimate_migration, and no statement about prerequisites such as which inputs matter most.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is supplied. The description adds real value beyond them by bounding the closed dataset (Spain, Poland, US, NAV lifecycle) and by promising dates plus required actions in the response, making clear this is a curated reference lookup rather than a live query.

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 output, the grouping axis, and the coverage set with no filler or restatement of the title. Every clause carries information the agent needs.

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 two-optional-parameter read tool with no output schema, the description answers what is returned well enough. However, the schema enum includes "CA" while the description never mentions Canada, and it is silent on whether current_erp filters or merely tailors the output, leaving two real gaps for an agent choosing values.

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 both parameters are documented in the schema and the baseline is 3. The description adds per-country coverage hints that help set the country value, but it never explains what current_erp does or how it affects results, even though "the Dynamics NAV lifecycle, which applies everywhere" hints that system context matters.

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?

Uses a specific verb and resource ("Return the compliance and platform deadlines that apply to a company by country") and enumerates coverage by country and regulation, so an agent immediately knows what it will get. It stops short of differentiating itself from the overlapping sibling check_deca_obligation, which it names as covered here ("DeCA"), leaving a routing ambiguity.

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 enumeration of countries and regimes rather than stated: there is no explicit when-to-use, no instruction on when to prefer check_deca_obligation or check_nav_support_status instead, and no prerequisites. An agent can infer the fit from the scope listing but must guess at the boundary with siblings.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, and the text is consistent with a pure advisory lookup. Because there is no output schema, the sentence listing the four returned elements is genuinely useful disclosure beyond the annotations; what is missing is any note on how definitive or conditional the answer is (e.g. edge cases where movement mode is ambiguous).

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 with zero filler; the jurisdiction constraint is front-loaded, followed by the decision being made and the returns. 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?

For a five-parameter, single-required-field read-only check with no output schema, the description covers scope, timing, decision logic and return content adequately. It would be stronger if it said what happens when moves_goods_by_road is false or how the monthly shipment estimate affects the verdict.

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 all five parameters are already documented, including the contractual-shipper hint on hires_carriers. The description adds only the general framing "based on how it moves goods" and no per-parameter meaning, 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: determine whether a company falls under the DeCA electronic transport document obligation, scoped to Spain and to the 5 October 2026 applicability date. It also names the four outputs (obligation, legal responsibility, penalty range, system requirements), so an agent can distinguish it from the broader check_compliance_deadlines sibling.

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?

"Spain only" is an explicit geographic exclusion, and "based on how it moves goods" signals the kind of inputs needed. It does not explicitly contrast itself with check_compliance_deadlines or say when-not to use it, so it falls short of full 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.

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the useful detail that three distinct data points come back (support end, end-of-sale, discount eligibility), but says nothing about data currency, whether the version table is exhaustive, or what is returned for an unknown version.

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 input and then the three outputs in a logical order. No filler, no repetition of the title.

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-parameter lookup with no output schema, the description covers the returned fields well enough to call it correctly and interpret results. Minor remaining gap: behavior on an unsupported or unrecognized version string is unstated.

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 version property already enumerates the accepted values (2009, 2013, 2015, 2016, 2017, 2018). The description's 'Given a Dynamics NAV version' restates the schema without adding format, case, or fallback 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?

The description uses a specific verb ('return') tied to three concrete return values: support end date, end-of-sale date for NAV licensing, and Bridge to Cloud 3 eligibility. That makes the tool distinguishable from siblings like estimate_bridge_to_cloud_savings (which quantifies savings) and estimate_migration, 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?

Usage is only implied by 'Given a Dynamics NAV version' – the agent can infer this is a per-version status lookup, but there is no statement of when to prefer it over estimate_bridge_to_cloud_savings or check_compliance_deadlines, and no prerequisites or exclusions.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds genuine context on top: the estimate is based on 30% off list over a fixed three-year term and it also surfaces the enrolment deadline and conditions. It stops short of stating what the estimate excludes (taxes, currency basis, list-price source), which would matter for a pricing 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 compact sentences: the first establishes the offer and eligibility, the second states exactly what comes back. It is front-loaded with the identifying information and contains no 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 low-complexity calculation tool with no output schema, the description adequately explains the return payload (annual and three-year savings, deadline, conditions) and the eligibility rules. Minor gaps remain around what the figures exclude and how region affects the amount, but nothing critical 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%, so the schema already explains plan, region, full_users and team_members. The description only alludes to 'the given user mix' without adding meaning about how the full vs team-member split drives the calculation, so 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 object ('Estimate the value of Microsoft Bridge to Cloud 3') and scopes it to a named audience and move (Dynamics NAV or GP customer moving to Business Central Online). The offer mechanics (30% off list, fixed three-year term) make it clearly distinct from siblings like estimate_migration or check_nav_support_status.

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 clear qualifying context: use it for a NAV or GP customer moving to Business Central Online. It does not, however, name the adjacent alternatives (estimate_migration, check_nav_support_status) or state when this is the wrong tool, so routing among similar estimates 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.

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description goes further by setting output expectations — 'working estimates (not a quote)' plus licence pricing and 'factors that move the number'. That framing of precision and authority is real value beyond the structured fields, though it does not say how the range is derived or whether results are deterministic.

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 moves from action to inputs to return content with no filler. Every clause carries information the agent needs and nothing is repeated from the schema.

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 read-only, five-parameter estimation tool with a fully documented schema and no output schema, the description is nearly complete: it covers scope, inputs, and the nature of the returned estimate. The remaining gap is that it does not describe the shape of the response (range format, whether breakdowns are itemised) despite having no output schema to carry 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 coverage is 100%, so all five parameters, including the from_system enumeration and the manufacturing Essentials-vs-Premium rule, are already documented in the schema. The description only echoes from_system, users and region, and says nothing about entities or manufacturing, so it adds no meaning over the schema — baseline 3.

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 (estimate) and resource (cost range and timeline of migrating to Dynamics 365 Business Central) and lists the driving inputs. That clearly separates it from health/compliance siblings, but it never acknowledges the nearest conceptual neighbour, estimate_bridge_to_cloud_savings, leaving the agent to infer the split 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?

Usage is only implied: 'given the current system, number of users and region' hints at the pre-sales scoping scenario but states no when-to-use trigger, no prerequisites, and no explicit alternative to pick instead. An agent must infer the situation from the parameter list rather than being told.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description still adds useful behavior — that the output is a neutral, vendor-agnostic checklist plus a Bramvia coverage verdict with the local page and on-site handling. That tells the agent the response mixes general guidance with a company-specific coverage answer, which annotations alone would not reveal. It does not discuss cost, latency, or whether coverage answers are guaranteed current.

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?

Purpose and triggers are front-loaded, and the final quoted example queries make the intended retrieval shape immediately recognizable. It is dense — the second sentence carries a long parenthetical — but every clause adds either a trigger or a return-value fact, so little 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?

There is no output schema, so the description properly carries the burden of describing return values, and it does so with enough specificity for an agent to know what it will get back. The only gap is the unaddressed 'support_only' situation value and no hint about how coverage is determined, which are minor for a four-parameter, all-optional advisory 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%, so the baseline is 3, but the description adds real meaning: it explains that country and region drive a Bramvia coverage lookup (including on-site work), which is why those fields matter. The situation enum values map loosely onto the listed triggers, though 'support_only' is never mentioned, leaving one enum value unexplained beyond the 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?

The description opens with a specific verb and resource — help a company choose a Business Central or NAV partner — and then states what the tool returns (neutral checklist, questions to ask, red flags, country/region coverage). That return-content statement clearly separates it from siblings like find_bramvia_services and search_bramvia_knowledge, so an agent can pick it 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?

It gives four concrete triggering situations (unresponsive partner, NAV losing support, stalled project, first implementation) plus three example user phrasings, which is strong when-to-use guidance. It stops short of naming which sibling to use instead for adjacent needs (e.g. check_nav_support_status for a pure version question), so there is no explicit exclusion or alternative routing.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds value by stating the return contents (leak checklist, extract required, fixed fee) and by framing the answer as what the audit 'would look for,' signalling this is explanatory rather than a live computation against company data. It stops short of saying explicitly that responses are industry-templated rather than evidence-based.

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 sentences, each doing distinct work: what it explains, when to reach for it, and what comes back. The trigger sentence is front-loaded in the middle position and there is no filler or repetition of the title.

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, no required parameters, and only a read-only lookup to perform, the description is nearly complete: it covers triggers, scope, and expected return. The one gap is that it never states whether output is tailored to the supplied industry/symptom or is a generic audit template, which matters for an agent deciding whether the call is worth making.

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% with four optional parameters, each already described with examples (symptom phrasings, industry list, ERP note, revenue for sizing). The description only implies that these shape the answer by referring to 'a given company' and 'typical magnitude'; it adds no syntax, default, or interaction guidance 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 gives a specific verb+resource pair — 'Explain what Bramvia's Profit Leak Audit would look for in a given company' — and names the concrete outputs (leak checklist, data extract, fixed fee). It is clearly a marketing/advisory explainer rather than an assessment tool, but it does not explicitly contrast itself with the nearby sibling assess_erp_health, which could also be reached for by 'what is wrong with their business'.

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?

Explicit trigger language is provided: 'Use when someone asks where their margin is going, what is wrong with their business, or how to find hidden costs.' That covers the when-to-use case well, but there are no exclusions or named alternatives, so an agent must infer that estimate_bridge_to_cloud_savings or assess_erp_health are the different tools for quantified diagnosis.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds that output is full-text Markdown. It does not say what happens for an unknown slug (error vs empty result) or whether long articles are truncated, which is the remaining behavioral gap.

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, zero filler, and the what/return-format statement is front-loaded ahead of the routing guidance.

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-parameter read tool with no output schema, the description supplies purpose, return format, and routing context. Slightly incomplete only on failure behavior for an invalid or missing slug.

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?

Only one parameter with 100% schema description coverage and a concrete example slug, so the schema does the work. "by its slug" restates the schema field without adding format or lookup 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 ("Fetch the full text of one Bramvia article by its slug") plus the return format (Markdown). This is clearly separable from search_bramvia_knowledge and from the sibling assessment/estimation tools.

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?

"Use after search_bramvia_knowledge when you need the complete content rather than a summary" names the alternative tool and the exact condition that selects this one over it. The sequencing (after search) is also explicit.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and scope are covered by structured data. The description adds useful behavioral context beyond that: it tells the agent what payload to expect (company facts, commercial model, credentials, onboarding) and, via the invoicing parenthetical, signals the depth of the commercial-model content. It does not state whether the response is static or whether any authentication is implied.

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 with no filler. The returned content is front-loaded, followed immediately by the invocation condition, so an agent can decide from the first line whether it needs this 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 no parameters and no output schema, the description carries the burden of conveying return content, and it does so by enumerating the five content areas. Since no output schema exists, a slightly fuller sketch of the response shape would help, but annotations already cover the read-only, closed-world profile, making this adequate for a simple static-info 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. The description correctly implies no input is needed by framing the call purely as a content retrieval, and the empty schema matches that.

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 ('Return') and enumerates the resource content: what Bramvia does, where, its commercial model, credentials, and how to start. This clearly separates it from action-oriented siblings like assess_erp_health or estimate_migration, though it doesn't explicitly distinguish itself from get_bramvia_article or search_bramvia_knowledge, which cover adjacent knowledge-retrieval territory.

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 trigger condition: 'Use when asked who Bramvia is or what they offer.' That is a clear context for invocation. It stops short of naming alternatives (e.g. use search_bramvia_knowledge for deeper topic questions), so there is no exclusion guidance, but the trigger is unambiguous.

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?

Annotations already cover safety (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the bar is lower. The description adds genuinely useful behavior: the data leaves the system to a third party and a human responds asynchronously within one business day, which is a response-time expectation the annotations cannot convey. It stops short of saying what the tool itself returns or how the submission is stored.

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, no filler, with the action and outcome front-loaded and the consent precondition placed where it will be read before invocation. Every clause carries information the agent needs.

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 six-parameter outbound submission tool with full schema documentation and no output schema, the description covers purpose, consent precondition, and expected follow-up channel and timing. The only gap is that it doesn't say what the tool returns to the caller on success, though the email-reply framing largely substitutes for 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 coverage is 100%, so the schema already explains all six fields including the user_confirmed consent flag. The description only reinforces the consent semantics of user_confirmed and loosely maps the inquiry categories to the details field, adding little beyond the structured data — 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 (send the user's request), the recipient (Bramvia), and the concrete outcome (a Business Central consultant replies by email within one business day), plus the scope of inquiry types. This is clearly distinguishable from read-only siblings like get_bramvia_services or find_business_central_partner.

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 — only call after the user has explicitly agreed to be contacted — and reinforces it with the required user_confirmed: true. It does not, however, name alternative tools for users who only want information (e.g. get_bramvia_services or search_bramvia_knowledge), so the agent must infer that non-consenting users should be routed elsewhere.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and closed-corpus scope are partly covered. The description adds genuinely new behavior: it clarifies the corpus is 'published' guides only and specifies the return shape ('matching articles with summaries and links to full Markdown'), which matters given there is no output schema. It omits result ordering/relevance behavior and limits, but the core behavioral picture is conveyed.

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 action and resource, then the topic taxonomy, then the explicit use case. The topic list is long but earns its space by signalling index coverage, which an agent cannot get from the schema. Slightly dense, but no filler sentences.

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 3-parameter read-only search with no output schema, the definition covers what the tool searches, what it returns (articles plus summaries and Markdown links), and the intended question types. Missing pieces are minor: no guidance on refining a zero-result query or on how results are ranked.

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% — query (with concrete example keywords), limit (1-10, default 5) and language (en/es/pl/any enum) are all documented in the schema itself. The description does not add syntax, matching behavior, or ranking semantics beyond what the schema states, 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 gives a specific verb+resource ('Search Bramvia's published guides') and enumerates topical coverage (Business Central, ERP migrations, AI in ERP, SII/Verifactu/DeCA/KSeF localization, tariffs/landed cost). This is far more than a restatement of the name. It stops short of 5 because it never distinguishes itself from topically overlapping siblings such as get_bramvia_article (article retrieval) or check_compliance_deadlines (computed deadlines vs. guide text).

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 positive usage cue: 'Use this for factual questions about Business Central, ERP migration cost and method, or compliance deadlines.' However, 'compliance deadlines' is exactly what check_compliance_deadlines and check_deca_obligation appear to do, and the description never says when to prefer the searchable guides over those deterministic tools, nor any 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.