Microsoft Dynamics 365 Business Central knowledge, Dynamics NAV lifecycle dates, ERP migration cost estimators and compliance deadlines by country. Ten tools, no authentication.
Scored across 10 tools
Most tools target clearly distinct actions, but check_compliance_deadlines overlaps somewhat with check_deca_obligation and check_nav_support_status since it also covers DeCA and Dynamics NAV lifecycle. The descriptions are specific enough to prevent most misselections, but a couple of boundary cases could require careful reading.
All tool names follow a consistent verb_noun snake_case pattern: assess_, check_, estimate_, find_, get_, and search_. The verbs map cleanly to their actions and the nouns describe the object or focus, making the tool set predictable and easy to navigate.
Ten tools is well-scoped for a consultancy knowledge and assessment server. Each tool covers a meaningful service or information need without redundancy or unnecessary expansion.
The surface covers the full apparent domain: company introduction, knowledge search and article retrieval, health assessments, compliance checks, migration estimates, profit leak diagnosis, and NAV/Bridge to Cloud specifics. No critical dead ends or obvious missing operations for the stated purpose.
Score the structural risk of a company's current ERP from a short description of its situation, the way Bramvia's ERP Health Check does. Returns a 0-100 score, the main risk drivers and a recommendation (leverage what you have, plan calmly, or act now).
| Name | Required | Description | Default |
|---|---|---|---|
| system | Yes | Current system: bc_cloud, bc_onprem, nav, other_updated, other_old, spreadsheets. | |
| support | No | Who maintains it. | |
| reporting | No | Where management reports come from. | |
| close_days | No | Working days to close the month. | |
| integrations | No | How other systems connect. | |
| customisation | No | How much custom code, and is it documented? | |
| compliance_plan | No | Is there a plan for upcoming compliance deadlines? |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral transparency burden. It discloses the return format (0-100 score, main risk drivers, recommendation) and names the three possible recommendation categories. It does not disclose how missing optional parameters are handled, but it clearly presents the tool as a non-mutating scoring function.
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 purpose is front-loaded, and the second sentence delivers the essential return-value details. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description correctly explains what will be returned, including the specific recommendation categories. With seven parameters, the schema covers their semantics, and the description covers the tool's overall behavior. It could have added guidance on how omitting optional parameters affects the score, but this is not a critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all seven parameters are documented structurally. The description adds no extra parameter-level detail beyond mentioning 'a short description of its situation', which is somewhat misleading since the inputs are structured enum fields rather than free-form text.
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?
Description states a specific verb ('Score') and resource ('structural risk of a company's current ERP'), and ties it to Bramvia's ERP Health Check concept. The output description (0-100 score, risk drivers, recommendation) makes it distinct from siblings like estimate_migration and check_compliance_deadlines.
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 the use case: assess structural risk from a short ERP situation description. However, it does not explicitly state when to prefer this tool over siblings such as estimate_migration, check_nav_support_status, or find_profit_leaks, and offers no exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the compliance and platform deadlines that apply to a company by country, with dates and what each one requires. Covers Spain (Verifactu, e-invoicing, DeCA, SII), Poland (KSeF), the United States (tariffs, pharmaceutical duty) and the Dynamics NAV lifecycle, which applies everywhere.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Country of operation. Default any. | |
| current_erp | No | Optional: current system, e.g. "NAV 2017", "Business Central", "Sage". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the scope of data returned (dates and requirements per country) and that the Dynamics NAV lifecycle applies everywhere, which is useful. However, it does not disclose whether the tool performs live lookups, whether results are filtered by the optional current_erp parameter, or what happens when country='any' is used. These are gaps, but the description does add meaningful behavioral context beyond the 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?
The description is a single, information-dense sentence that front-loads the core purpose and then lists coverage. It is efficient and every clause adds value. It could be slightly more structured (e.g., separating the coverage list from the behavior), but it is not bloated.
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 lookup tool with two optional parameters and no output schema, the description is largely complete: it states what is returned, for which countries, and that the NAV lifecycle is global. The main missing piece is how current_erp influences the results, but the tool is simple enough that this 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 100%, so the schema already documents both parameters. The description adds context by naming the countries and regulations, which helps an agent understand what values like 'ES' or 'PL' map to, but it does not explain how current_erp affects the results. Baseline 3 is appropriate since the schema does the heavy lifting.
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 ('Return') and resource ('compliance and platform deadlines'), and enumerates the exact countries and regulations covered (Spain's Verifactu, e-invoicing, DeCA, SII; Poland's KSeF; US tariffs and pharmaceutical duty; Dynamics NAV lifecycle). This clearly distinguishes it from sibling tools like check_deca_obligation or check_nav_support_status, which are narrower in scope.
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 when to use this tool: when you need compliance/platform deadlines by country. It names the covered countries and the Dynamics NAV lifecycle, which helps an agent choose it over more specific siblings like check_deca_obligation or check_nav_support_status. However, it does not explicitly state when NOT to use it or name alternatives, so it falls just 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.
Spain only. Determine whether a company is affected by the DeCA (documento de control) electronic transport document obligation that applies from 5 October 2026, based on how it moves goods. Returns the obligation, who is legally responsible, the penalty range and what the system must produce.
| Name | Required | Description | Default |
|---|---|---|---|
| own_fleet | No | Does it operate its own vehicles? | |
| hires_carriers | No | Does it contract hauliers rather than owning the trucks? (Contractual shipper duties apply.) | |
| international_only | No | Is all transport international (CMR) rather than national? | |
| moves_goods_by_road | Yes | Does the company ship or receive goods by road in Spain? | |
| shipments_per_month | No | Approximate road shipments per month. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal a key behavioral nuance: the obligation applies from a specific future date, and the tool returns legal responsibility and penalty ranges. However, it doesn't clarify whether the tool performs exhaustive checks or provides definitive legal advice, nor does it mention any input validation or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, clearly front-loading the geographic scope and core purpose. Every sentence adds value: the first states the scope and purpose, the second lists the outputs. It is efficient and structured for quick comprehension, with 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 tool with no output schema, the description adequately summarizes the expected outputs (obligation, responsible party, penalty range, system requirements). However, it doesn't specify the exact format of those outputs (e.g., structured fields vs. prose), which could be important for an agent. Given the tool's complexity (5 parameters, 100% schema coverage), it is largely complete but could benefit from a note on edge cases (e.g., future date applicability).
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 schema description coverage is 100%, so all parameters are already described. The description does not add new meaning but reinforces that the tool is about how goods move. The parameter descriptions, especially for hires_carriers, already include explanatory notes about shipper duties. The description's reference to 'how it moves goods' does add a slight framing but is not essential.
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 clearly states what the tool does: determines DeCA obligation based on how goods are moved, and explicitly lists the outputs (obligation, responsible party, penalty range, system requirements). It specifies the jurisdiction (Spain) and effective date (5 October 2026), making it distinct from any generic compliance 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?
The description specifies the tool is for Spain only, giving a clear geographic context. However, it does not explicitly state when NOT to use it (e.g., outside Spain) or mention alternatives among siblings (like check_compliance_deadlines). It implies use for DeCA-related queries, but lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate the value of Microsoft Bridge to Cloud 3 for a Dynamics NAV or GP customer moving to Business Central Online: 30% off list for a fixed three-year term. Returns annual and three-year savings for the given user mix, plus the enrolment deadline and the conditions.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | No | Default essentials. | |
| region | No | Default US. | |
| full_users | Yes | Users who create transactions (Essentials or Premium). | |
| team_members | No | Read-only, approval and time-entry users. Default 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden. It discloses the outputs (annual and three-year savings, enrolment deadline, conditions) and key terms, but does not explicitly state that the tool is read-only or mention any assumptions or limitations. It is adequate but not rich in behavioral detail beyond the outputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose and then packs in the key commercial details and outputs. There is no redundancy or filler, making it efficiently structured.
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 calculation tool with no output schema, the description names the return values (annual/three-year savings, deadline, conditions) and the input domain. It omits specifics like units or formatting, but given the simplicity of the tool and full schema coverage, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with descriptions (coverage 100%), so the description does not need to repeat them. It does add the phrase 'given user mix' which hints at the interaction between parameters, but this adds minimal extra meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely identifies the tool's purpose: estimating savings for Bridge to Cloud 3 for Dynamics NAV/GP customers migrating to Business Central Online, including the 30% discount and three-year term. It clearly distinguishes from siblings like 'estimate_migration' by focusing on savings rather than migration aspects.
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 explicitly states the target scenario (NAV/GP moving to Business Central Online) and the promotional specifics (30% off list, three-year term), giving clear context for when to use. However, it does not explicitly mention when not to use or direct to alternatives, but the context is strong enough to place it above a generic 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate the cost range and timeline of migrating to Dynamics 365 Business Central, given the current system, number of users and region. Returns Bramvia working estimates (not a quote) plus licence pricing and the factors that move the number.
| Name | Required | Description | Default |
|---|---|---|---|
| users | Yes | Total people who will use the system. | |
| region | No | Where the company operates. Default US. | |
| entities | No | Number of legal entities. Default 1. | |
| from_system | Yes | One of: nav, gp, netsuite, quickbooks, sap_b1, sage, odoo, a3erp, holded, enova, spreadsheets, stalled. | |
| manufacturing | No | Does the company manufacture or run field service? Decides Essentials vs Premium. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose that the tool returns 'working estimates (not a quote)' and includes licence pricing and factors that move the number, which is useful. However, it does not disclose whether this is a read-only operation, whether it makes external calls, or any rate limits or side effects. For a non-destructive estimation tool, the lack of annotations is a gap, but the description adds meaningful context about the nature of the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose and then adds the key qualifier about working estimates. Every clause earns its place, and it is appropriately sized for the tool's complexity.
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 tool with no output schema, the description does a good job of explaining what the agent will get back: a cost range, timeline, licence pricing, and factors that move the number. It also covers the main inputs. It doesn't mention edge cases like missing region defaults or how to handle unsupported from_system values, but the schema already covers defaults and enums. Overall, it is complete enough for an agent to call it correctly.
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 documents all five parameters. The description adds context by naming the key inputs (current system, number of users, region) and explaining that manufacturing decides Essentials vs Premium, which is not in the schema. However, it doesn't add detail on how the parameters interact or what values are expected beyond the schema, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Estimate'), a clear resource (cost range and timeline of migrating to Dynamics 365 Business Central), and the key inputs (current system, number of users, region). It also distinguishes the output from a quote, which helps an agent understand what this tool is for. It is clearly differentiated from siblings like estimate_bridge_to_cloud_savings, which targets a different migration scenario.
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 when to use this tool: when an agent needs a working estimate for a Business Central migration, given the current system, users, and region. It does not explicitly state when not to use it or name alternatives, but the context signals and sibling names (e.g., estimate_bridge_to_cloud_savings) make the use case reasonably clear. It lacks explicit exclusions or alternative routing, so it doesn't earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain what Bramvia's Profit Leak Audit would look for in a given company, with the typical magnitude of each leak and the data needed to quantify it. Use when someone asks where their margin is going, what is wrong with their business, or how to find hidden costs. Returns the leak checklist, the extract required and the fixed fee.
| Name | Required | Description | Default |
|---|---|---|---|
| symptom | No | What the company notices: e.g. "margin fell but revenue held", "cash is tight", "we are always expediting". | |
| industry | No | e.g. manufacturing, wholesale distribution, food, chemicals, construction, services. | |
| current_erp | No | Optional: their current system. The audit works on any ERP. | |
| annual_revenue_musd | No | Optional: approximate annual revenue in millions, to size the leaks. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns a leak checklist, the extract required, and a fixed fee, which gives behavioral transparency about the output. It also implies the tool is advisory/analytical rather than destructive, but doesn't explicitly state permissions or side effects. Given no annotations, the description does provide substantial context, so a 4 is justified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, three sentences with no fluff. It front-loads the primary purpose and includes usage and return info efficiently. Slightly more could be said but it is well-structured and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description effectively covers what it returns (leak checklist, extract, fee) and its purpose. It also lists the key parameters implicitly. The tool is illustrative in nature, so the description is complete enough for most use cases, though it could mention that it is a question-answering tool rather than a data 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 high (100%) for 4 parameters, all with detailed descriptions (e.g., 'symptom' as what the company notices, 'industry' with examples). The description does not add additional semantics beyond the schema, such as parameter constraints or relationships, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear purpose: it explains what Bramvia's Profit Leak Audit would look for, including the magnitude of each leak and data needed. It specifies the verb 'explain' and the resource 'Profit Leak Audit', distinguishing it from siblings by focusing on profit leaks and audit explanation, not ERP health or compliance deadlines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Use when someone asks where their margin is going, what is wrong with their business, or how to find hidden costs.' This helps an agent decide when to invoke this tool, though it doesn't explicitly mention when not to use it or contrast with alternative tools (e.g., assess_erp_health), but the use cases are clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full text of one Bramvia article by its slug, as Markdown. Use after search_bramvia_knowledge when you need the complete content rather than a summary.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Article slug, e.g. "dynamics-nav-end-of-life-2028-2031-deadlines-us". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the return format (Markdown) and the scope (full text vs summary), which is useful. However, it doesn't disclose potential failure modes (e.g., what happens if the slug doesn't exist), rate limits, or whether the article content is cached or fetched live. For a simple read operation, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence states the action, resource, identifier, and output format. The second sentence gives usage guidance. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema, the description covers the essential information: what to pass, what to expect back, and when to use it. The only minor gap is error behavior for invalid slugs, but that is not critical for an agent to invoke the tool correctly.
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 documents the slug parameter with an example. The description adds the context that the slug identifies a Bramvia article and that the output is Markdown, but it doesn't add meaning beyond the schema's example. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Fetch'), a specific resource ('full text of one Bramvia article'), and the exact identifier ('by its slug'), plus the output format ('as Markdown'). It clearly distinguishes itself from the sibling search_bramvia_knowledge by specifying it returns complete content rather than a summary.
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 explicitly says to use this tool after search_bramvia_knowledge when complete content is needed rather than a summary. This gives the agent a clear when-to-use directive and implicitly identifies the alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return what Bramvia does, where, its commercial model (each project part invoiced only after the client accepts it), credentials, and how to start. Use when asked who Bramvia is or what they offer.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It clearly indicates this is a non-mutating retrieval operation ('Return') and specifies what content is returned, including the distinctive invoicing model. It doesn't discuss side effects, auth, or rate limits, but for a zero-parameter lookup tool this is sufficient.
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 efficient sentences: the first front-loads the full output scope, and the second gives the usage trigger. Every phrase adds information, with no repetition 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 simple zero-parameter information-retrieval tool with no output schema, the description fully covers what the agent can expect and when to call it. No additional operational details are needed.
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 has zero parameters and 100% schema description coverage, so the baseline is 4. The description does not need to add parameter-level meaning because there are no inputs to explain.
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 ('Return') and a clear resource: an overview of Bramvia, covering what it does, locations, commercial model, credentials, and how to start. This distinguishes it from siblings like get_bramvia_article and search_bramvia_knowledge, which are narrower content-retrieval 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?
It explicitly states when to use the tool: 'when asked who Bramvia is or what they offer.' It does not name alternatives or exclusions, but the trigger is clear enough for an agent to route this class of question correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Bramvia's published guides on Dynamics 365 Business Central, ERP migrations, AI in ERP delivery, profitability diagnosis, Spanish/Polish localization (SII, Verifactu, DeCA, KSeF) and US/Canada topics (tariffs, landed cost, cyber insurance, NAV end of life). Returns matching articles with summaries and links to full Markdown. Use this for factual questions about Business Central, ERP migration cost and method, or compliance deadlines.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, 1-10. Default 5. | |
| query | Yes | Keywords or a question, e.g. "NAV end of support", "deadstock", "KSeF", "Essentials vs Premium". | |
| language | No | Preferred article language. Default any. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that the tool searches published guides and 'Returns matching articles with summaries and links to full Markdown,' which informs the agent of the output shape and non-mutating nature. It does not mention ranking, freshness, or coverage limitations, but for a search tool the disclosed behavior is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler: it states the search scope, return format, and primary use case efficiently. The topic list is long but directly useful for an agent deciding whether to invoke 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?
For a stateless search tool with three well-documented parameters and no output schema, the description covers what is searched, what is returned, and when to use it. It lacks only minor details such as result ordering or coverage guarantees, but nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the parameters. The description adds domain-level context by listing the kinds of topics to search for, but it does not add meaningful per-parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search' and the resource 'Bramvia's published guides', and it enumerates the topical scope (Business Central, ERP migrations, compliance, localization, US/Canada topics). It does not explicitly differentiate itself from siblings such as get_bramvia_article or check_compliance_deadlines, but the search-and-return-articles framing is distinct enough.
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 explicit usage context: 'Use this for factual questions about Business Central, ERP migration cost and method, or compliance deadlines.' This tells the agent when to select this tool, but it does not state when not to use it or name specific alternatives for overlapping sibling tools like estimate_migration or check_compliance_deadlines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
assess_erp_healthcheck_compliance_deadlinescheck_deca_obligationcheck_nav_support_statusestimate_bridge_to_cloud_savingsestimate_migrationfind_profit_leaksget_bramvia_articleget_bramvia_servicessearch_bramvia_knowledge
Add one secure layer between your agents and this server.
