Server Quality Checklist

Tool Scores

• bc_list_companiesA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden and does well. It discloses internal behavior (opens and closes the BC Companies system page), states it does not affect open pages or session state, and confirms no parameters are required. It lacks mention of potential errors or permissions, but for a list operation 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured across three short paragraphs: purpose/return, internal behavior, and usage guidance. Each sentence adds value, though slightly longer than strictly necessary. It is front-loaded with the core purpose in the first sentence.

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

  Completeness4/5

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

  For a zero-parameter tool with no output schema, the description is complete: it states the return content, side effects, internal mechanism, and when to use alternatives. It does not detail the exact array structure, but the absence of an output schema is mitigated by describing the returned information.

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

  Parameters4/5

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

  The tool has zero parameters, and the schema documents this completely. The description adds the explicit confirmation that no parameters are required, which is consistent. With no parameters to explain, the baseline of 4 applies.

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

  Purpose5/5

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

  The description clearly states the tool lists all companies in the current Business Central environment and returns an array of company names plus the active company. It uses a specific verb plus resource, and explicitly distinguishes itself from bc_switch_company and other sibling tools.

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

  Usage Guidelines5/5

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

  The description provides explicit when-to-use guidance: use before bc_switch_company to verify target company existence. It also gives a clear exclusion: do NOT use if you already know the company name, and directs to alternatives (bc_switch_company directly, or bc_switch_company followed by bc_open_page).

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

• bc_open_pageA
  4.6/5.0
  Behavior5/5

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

  With no annotations, the description carries full responsibility for behavioral disclosure. It reveals that the header section changes shape depending on page type, details the section structure (kind, content shape), and stresses the correct handling of enum fields ('Always use the "value" string from "options"'). It also signals a session-like open/close lifecycle, giving the agent a complete behavioral model.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but appropriately sized for a tool with significant behavioral complexity. It is front-loaded with the core purpose and organized into logical blocks (sections, workflow, examples). Some repetition of the header shape concept exists, but overall every sentence serves a purpose.

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

  Completeness5/5

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

  Given there is no output schema, the description thoroughly documents the return structure, including section kinds, card/list shapes, and enum/option handling. It covers the complete lifecycle from opening to closing, alternative tools, and page-type examples, leaving the agent well-equipped to use the tool confidently.

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

  Parameters3/5

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

  The schema already describes all three parameters with 100% coverage, so the baseline is 3. The description adds illustrative examples (pageId 22 vs 21 with bookmark) and clarifies that bookmarks come from list rows, but it does not fundamentally add meaning beyond what the schema already provides.

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

  Purpose5/5

  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 ('Opens a Business Central page by its numeric page ID') and clearly distinguishes itself from siblings: it is the entry point for page-scoped work, while bc_query is for bulk read-only data and bc_search_pages finds IDs. This makes the tool's purpose unambiguous and well-scoped.

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

  Usage Guidelines5/5

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

  The description explicitly tells when to use this tool vs alternatives: 'For bulk, read-only data over standard entities, prefer bc_query' and 'Use bc_search_pages first if you do not know the page ID.' It also warns against calling when already open and instructs to close with bc_close_page, providing clear context and exclusions.

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

• bc_lookupA
  4.8/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and does so thoroughly. It discloses that the operation is non-mutating, opens the lookup form, always cancels without selecting, and leaves the source page field unchanged. It also states that lookupCustom=true results in a clear error, which is valuable behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with a one-sentence purpose definition, then organized into usage, exclusions, and workflow. Every sentence contributes practical value, and examples clarify the intended use without padding.

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

  Completeness4/5

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

  The description covers purpose, usage, exclusions, workflow, side effects, and error behavior, but since there is no output schema, it stops short of specifying the exact shape of returned result rows beyond 'candidate values' and 'result rows.' This is a minor gap for a tool whose primary output is a list of rows.

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

  Parameters4/5

  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. The description adds extra meaning beyond the schema by explaining the workflow prerequisites (pageContextId from bc_open_page), how the search string filters via BC's native search, and the maxRows default/cap. This enriches parameter understanding beyond raw schema text.

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

  Purpose5/5

  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: 'Enumerates candidate values for a related-table (FK) field by invoking BC's built-in Lookup.' It clearly distinguishes bc_lookup from siblings like bc_write_data and bc_read_data by scoping it to lookup candidate enumeration on open pages.

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

  Usage Guidelines5/5

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

  The description gives explicit when-to-use guidance ('Use this when you need to see valid choices for a field before writing it'), plus clear exclusions: not for option/enum fields, not for fields where isLookup is false or absent, and not for lookupCustom=true fields. It also provides a concrete workflow sequence.

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

• bc_close_pageA
  4.9/5.0
  Behavior5/5

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

  Since no annotations are provided, the description carries the full burden of behavioral disclosure. It transparently explains that the pageContextId becomes invalid after closing, that it is safe to call even after prior errors, and that it frees specific server-side resources (WebSocket form session). This is rich 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded with the primary purpose. Every sentence adds value: purpose, resource implications, requirement, invalidation warning, safety, and explicit don'ts. There is no fluff or redundancy.

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

  Completeness5/5

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

  For a single-parameter tool with no output schema, the description is complete. It covers what the tool does, when to use it, what side effects occur, safety properties, and exclusions. No critical information is missing for an agent to invoke it correctly.

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

  Parameters4/5

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

  The schema already provides 100% coverage for the single parameter pageContextId, so the baseline is 3. The description adds meaningful lifecycle semantics: 'Requires a pageContextId from bc_open_page. After closing, the pageContextId becomes invalid.' This helps the agent understand the parameter's provenance and post-conditions.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Closes an open Business Central page and frees its server-side resources including the WebSocket form session.' This is a specific verb+resource combination, and it distinguishes the tool from its siblings (e.g., bc_open_page, bc_read_data) by focusing on the closing action and resource cleanup.

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

  Usage Guidelines5/5

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

  Explicit guidance is provided: 'Always call this when you are finished working with a page to prevent resource leaks' and 'Do NOT call this in the middle of a multi-step workflow' and 'Do NOT call this to reset a page; use bc_read_data to refresh data instead.' This clearly states when and when not to use it, and even references an alternative for resetting.

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

• bc_execute_actionA
  4.9/5.0
  Behavior5/5

  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 thoroughly explains the execution flow: validates the action, sends the InvokeAction RPC, applies events, and returns updatedFields/changedSections/dialogsOpened/openedPages. It also discloses confirmation dialog behavior, row-scoped action requirements, the staleness guard with expectedStateVersion and STALE_CONTEXT rejection, and that passing both action and cue is an error. This is exemplary transparency for a mutation tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Although lengthy, the description is densely informative and well-structured. It opens with a clear summary, then breaks down each mode, usage constraints, dialog handling, row targeting, staleness guard, exclusions, and ends with six concrete examples. Every sentence adds operational value; no filler or redundancy is present. The bulleted examples at the end are particularly effective for comprehension.

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

  Completeness5/5

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

  For a tool with two modes, 7 parameters, and complex interactions (dialogs, row targeting, staleness), the description provides comprehensive context. It covers prerequisites (pageContextId from bc_open_page), error conditions (STALE_CONTEXT, passing both action/cue), return values (updatedFields, dialogsOpened, etc.), and exclusions. Even without an output schema, the description sufficiently explains what the agent can expect and how to react (e.g., follow-up with bc_respond_dialog).

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

  Parameters4/5

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

  Since the schema already describes all 7 parameters with 100% coverage, the baseline is 3. The description adds significant value by explaining when to use action vs cue, how section disambiguates header vs line actions, the meaning of rowIndex/bookmark for row-scoped actions, and the expectedStateVersion staleness mechanism. It also provides concrete examples mapping parameters to realistic calls, which helps the agent understand parameter interactions beyond the schema definitions.

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

  Purpose5/5

  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: 'Executes either a named action OR a cue-tile drill-down on an open page.' It clearly distinguishes two modes of operation and establishes scope (open page from bc_open_page). This differentiates it from sibling tools like bc_write_data and bc_navigate, which are explicitly mentioned as alternatives.

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

  Usage Guidelines5/5

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

  The description provides explicit usage rules: 'Use exactly one of action or cue -- passing both is an error.' It gives clear contextual direction, such as requiring section for cue drill-down and pageContextId from bc_open_page. It also lists when NOT to use the tool: 'Do NOT use this for writing field values -- use bc_write_data. Do NOT use this to open records from a list -- use bc_navigate with drill_down action instead.' This exceeds simple guidance by identifying exact alternatives.

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

• bc_navigateA
  4.9/5.0
  Behavior5/5

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

  With no annotations provided, the description fully carries the behavioral burden. It discloses that select does NOT open the record or return new data, drill_down returns a NEW pageContextId and leaves the original page open (requiring bc_close_page for both), and that navigation only works on repeater rows. These are critical behavioral traits beyond any schema or annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured: a one-sentence purpose summary, then action-by-action details, a section-targeting note, explicit warnings, and examples. While longer than many descriptions, every sentence earns its place—no filler—and the use of bullet-like paragraphs and a compact example block aids scannability.

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

  Completeness5/5

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

  The tool has no output schema, so the description must explain return behavior itself. It does: select 'does NOT return new data,' drill_down 'Returns a NEW pageContextId for the opened Card/Document page with its full state.' It also covers prerequisites, section handling, and page-closing responsibilities, making it complete for an agent to invoke correctly.

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

  Parameters4/5

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

  Schema coverage is 100% (every parameter has a description), so the baseline is 3. However, the description goes well beyond the schema by explaining the action enum behavior in narrative form, clarifying the source of bookmark/pageContextId (from bc_open_page or bc_read_data), and providing concrete JSON examples for select vs drill_down with optional section. This added meaning justifies a 4.

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

  Purpose5/5

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

  The description opens with a specific verb+resource: 'Navigates to a specific record on an open Business Central List or Document page using its bookmark.' It clearly distinguishes the two supported actions (select vs drill_down) and differentiates itself from sibling tools by explicitly stating what it does not do (field-level lookups via bc_lookup, direct row targeting via bc_execute_action). This is a model of purpose clarity.

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

  Usage Guidelines5/5

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

  The description provides explicit when-to-use and when-not-to-use guidance. It states 'bc_execute_action can target a row directly... so you usually do not need a separate select before an action like Delete,' and 'For field-level lookups... use bc_lookup, not this tool.' It also warns 'Do NOT use this for Card pages -- it only works on pages with repeater rows,' giving clear exclusions and alternatives.

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

• bc_read_dataA
  4.9/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and does so thoroughly. It discloses the return shape, the stateVersion mechanism for stale-state rejection, filtering behavior (list-shape only, AND logic), clearFilters interplay with SourceTableView filters, sorting viewport reset and rejection of non-sortable columns, and the default section behavior. These are non-obvious behavioral traits that go well beyond the schema and give the agent critical context for invoking the tool safely and effectively.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but well-structured, with the main purpose up front and then systematic sections for filtering, clearing, sorting, columns, and range slicing, followed by examples. It is somewhat verbose, with a few repetitive examples (e.g., sort examples), but each section earns its place by adding necessary behavior details. The front-loading and clear separation make it navigable despite its length.

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

  Completeness5/5

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

  Given the tool's complexity (8 parameters, nested objects, no output schema), the description is remarkably complete. It covers prerequisites, alternatives, return value structure, all parameter behaviors, and demonstrates common workflows with examples. It even explains the enum/option writing convention that matters for subsequent bc_write_data calls. No important gaps are apparent.

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

  Parameters5/5

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

  Although schema coverage is 100%, the description adds substantial meaning beyond the schema. It provides concrete examples for filters (exact, range, wildcard, expression), clarifies sort direction with A-Z/0-9 and viewport reset, explains clearFilters ordering ('Runs before any filters[] in the same call'), and gives specific section values like 'lines' and 'factbox:Customer Statistics'. This is exactly the kind of extra semantic detail that helps an agent use the parameters correctly.

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

  Purpose5/5

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

  The description states a specific action: 'Refreshes a single section on an already-open page.' It immediately distinguishes from sibling bc_query for bulk reads, explicitly saying 'Do NOT use this for bulk or analytical reads... prefer bc_query,' and clarifies when to use this tool: 'when you need the interactive page's exact rows, factboxes, or option metadata.' This is a crisp verb+resource+scope with clear sibling differentiation.

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

  Usage Guidelines5/5

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

  The description gives explicit prerequisites ('Requires a pageContextId from a prior bc_open_page call'), exclusions ('Do NOT use this for bulk or analytical reads over standard entities... prefer bc_query'), and positive usage conditions ('Use bc_read_data when you need the interactive page's exact rows, factboxes, or option metadata'). It also explains the difference from bc_query (server-side OData vs. interactive page state), which is exactly the kind of alternative guidance needed.

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

• bc_respond_dialogA
  4.9/5.0
  Behavior5/5

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

  No annotations exist, so the description carries full burden. It thoroughly explains response semantics ('ok'=confirm, 'cancel'=dismiss, 'abort'=force-close), the need to check changedSections after responding, and the possibility of chained dialogs. It also warns against misuse, which discloses operational constraints.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but highly structured: purpose, trigger conditions, response values, post-response behavior, warnings, and an example. Every sentence adds practical guidance, and the example concretely ties the parameters together. No redundant or filler content.

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

  Completeness5/5

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

  With no output schema, the description explains what to inspect after the call (changedSections) and how to handle chained dialogs by checking for a new dialogsOpened array. It also covers the source of dialogFormId and the permissible responses, making it complete for this dialog-response workflow.

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

  Parameters4/5

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

  Schema coverage is 100%, so the baseline is 3. The description adds value by advising which response to choose ('confirmation dialogs typically need yes, acceptance dialogs need ok') and by giving a complete example. However, the schema already describes each parameter's origin, so the added semantics beyond schema are modest.

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

  Purpose5/5

  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: 'Responds to an open Business Central dialog or confirmation prompt.' It clearly distinguishes the tool from siblings by explaining it handles dialogs triggered by bc_execute_action, bc_write_data, or bc_run_report, making its role unambiguous.

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

  Usage Guidelines5/5

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

  Uses explicit conditional language: 'you MUST call this tool' when dialogsOpened has requiresDialogResponse: true or bc_run_report returns a requestPage. It also provides firm negative guidance: 'Do NOT call this without a preceding dialog' and 'Do NOT guess the dialogFormId.' This leaves no ambiguity about when to invoke the tool.

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

• bc_run_reportA
  4.9/5.0
  Behavior5/5

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

  With no annotations, the description carries the full transparency burden and excels. It discloses that the report runs server-side, internally drives the BC 'Send to...' flow, selects formats via SaveValue, fetches files from DynamicFileHandler.axd, saves to disk when BC_REPORT_DIR is set, and returns errors listing available formats if the requested format is unavailable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but densely informative. It is front-loaded with the primary purpose, then methodically covers the request-page flow, format-capture flow, environmental side effect, format availability caveat, usage exclusions, and examples. Every sentence contributes necessary context, with no filler.

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

  Completeness5/5

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

  Despite the absence of an output schema, the description fully explains return values (requestPage fields, download.bytes, contentType, fileName, savedPath) and how to integrate with sibling tools (bc_write_data, bc_respond_dialog). It also lists common report IDs, making the tool immediately actionable.

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

  Parameters4/5

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

  The input schema already provides detailed descriptions for both parameters (100% coverage), so the baseline is 3. The description adds extra value with concrete usage examples, the behavior when format is omitted, and nuanced format selection rules ('pdf' is default, 'excel' prefers data-only, 'word' targets options containing 'Word'), justifying a 4.

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

  Purpose5/5

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

  The description starts with a specific verb and resource: 'Execute a Business Central report by its numeric report ID.' It clearly distinguishes reports from pages and explicitly names alternative tools for data retrieval, leaving no ambiguity about the tool's role.

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

  Usage Guidelines5/5

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

  The description gives explicit when-to-use guidance: 'Use this tool for reports that perform server-side actions... or to inspect and fill request page parameters.' It also states when not to use it: 'Do NOT use for viewing data -- use bc_open_page and bc_read_data,' and names concrete alternatives.

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

• bc_search_pagesA
  4.9/5.0
  Behavior5/5

  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 discloses the profile-scoped nature of Tell Me, the empty-result behavior with a 'note' field, that runTarget is an AL name rather than a numeric ID, and the need to map the AL name to a page ID for opening. It also specifies the exact return object structure. This is rich, honest disclosure that goes beyond any structured metadata.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Although the description is long, every sentence serves a purpose: purpose, usage boundaries, environment caveat, result format, empty-result handling, and examples. It is front-loaded with the primary purpose and then layers essential context. No fluff or repetition; the length is justified by the tool's complexity and lack of annotations.

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

  Completeness5/5

  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, no annotations, and only one parameter, the description is remarkably complete. It covers the full lifecycle: what it does, when to use it, how the environment affects it, the structure of results, the empty-result note, and a concrete example. There are no significant gaps left for an agent to guess about.

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

  Parameters4/5

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

  The input schema already provides 100% coverage for the 'query' parameter with a clear description and examples, so the baseline is 3. The tool description adds value by showing concrete query-to-result examples (e.g., 'customer' returns 'Customer List') and explaining how the query maps to the search behavior, thereby enriching the parameter semantics slightly beyond the schema. This justifies a 4.

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

  Purpose5/5

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

  The description clearly states the tool searches BC's Tell Me index for pages, reports, codeunits, and other run-targets, and explicitly distinguishes itself from siblings by specifying when to use it (when page ID is unknown) and when not (when ID is already known, use bc_open_page; for data reading, use other tools). The verb 'searches' plus the specific resource and scope make the purpose unambiguous.

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

  Usage Guidelines5/5

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

  The description provides explicit when-to-use and when-not-to-use guidance: it is for discovery when the page ID is unknown, not for opening pages with a known ID, and not for reading data. It also names alternatives (bc_open_page) and gives context about the profile-scoped Tell Me index and remediation via BC_PROFILE. This is exemplary usage guidance.

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

• bc_switch_companyA
  4.9/5.0
  Behavior5/5

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

  Despite no annotations, the description fully discloses critical side effects: open pages are invalidated and pageContextIds become unusable, requiring bc_open_page to re-open pages. It also explains the scope of the switch on future calls, which is essential behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a clear opening statement, a warning about page invalidation, usage instructions, a caution against improper workflows, and an example. Every sentence serves a purpose without redundancy.

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

  Completeness5/5

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

  For a single-parameter tool with no annotations or output schema, the description is remarkably complete. It covers purpose, prerequisites, side effects, post-switch behavior, and exclusions, leaving little ambiguity for the agent.

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

  Parameters4/5

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

  The schema already describes companyName as an exact name and suggests using bc_list_companies. The description reinforces this and adds a concrete example, increasing clarity. Given 100% schema coverage, this is a strong bonus beyond the baseline.

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

  Purpose5/5

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

  The description clearly states the tool's function: switching to a different company within the current Business Central session. This distinguishes it from siblings like bc_list_companies (which lists companies) and bc_open_page/read/write/execute (which operate within a company context).

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

  Usage Guidelines5/5

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

  The description provides explicit guidance: use bc_list_companies first to verify the target company, avoid switching mid-workflow, and complete current operations first. It also clarifies that subsequent calls operate on the new company, effectively explaining when to invoke this tool relative to others.

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

• bc_write_dataA
  4.9/5.0
  Behavior5/5

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

  No annotations are provided, so the description fully carries the burden. It discloses that BC validates fields and returns server-confirmed values that may differ due to formatting, auto-completion, or lookups. It also explains error conditions (read-only fields), cascading validation behavior, and the STALE_CONTEXT rejection mechanism with expectedStateVersion. This is deeply transparent about side effects and 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Despite being lengthy, every sentence earns its place. The structure is logical: core behavior, caveats, targeting options, staleness guard, exclusions, and examples. The front-loaded purpose sentence immediately orients the agent, and the examples are compact and varied. No redundant filler is present.

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

  Completeness5/5

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

  Given the tool's complexity—6 parameters, nested objects, line targeting, staleness guard, and error modes—the description covers all necessary context. It explains return values (confirmed values), error cases, and operational nuances. There is no output schema, but the description adequately covers what the agent needs to know. The exclusions and alternatives are also fully addressed.

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

  Parameters4/5

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

  The input schema already covers all 6 parameters with 100% description coverage, so the baseline is 3. The description adds value through concrete examples (card, line, bookmark, staleness guard) and clarifies the fields object structure and the meaning of rowIndex vs bookmark. It reinforces and extends schema details, but does not introduce entirely new semantics, hence a 4.

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

  Purpose5/5

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

  The description immediately states a specific verb and resource: 'Writes one or more field values on an already-open Business Central page.' It clearly differentiates from siblings by explicitly excluding actions (bc_execute_action) and navigation (bc_navigate). The scope is precise and unambiguous.

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

  Usage Guidelines5/5

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

  Provides explicit when-to-use guidance: write field values, write related fields together, use bookmark over rowIndex when rows may be reordered. Also gives direct exclusions: 'Do NOT use this for triggering actions... use bc_execute_action instead' and 'Do NOT use this for navigating... use bc_navigate instead.' This level of alternative guidance is exemplary.

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

• bc_queryA
  5/5.0
  Behavior5/5

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

  With no annotations, the description bears full responsibility and delivers. It discloses that the tool is read-only, mentions server-side filtering/projection, explains the top default (100), company scoping with the companies entity exception, and even details auth requirements (Basic vs OAuth) for the environment.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Although long, the description is well-structured and front-loaded with the core purpose. Every section (what, when, when not, entity list, param examples, auth notes) earns its place, and the use of headers makes it easy to scan for key decision points.

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

  Completeness5/5

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

  For a complex tool with 7 parameters, no annotations, and no output schema, this description covers all essential context: purpose, usage guidance, entity list, parameter semantics, defaults, company scoping, and environment-specific auth. It leaves no critical gap for an agent deciding whether and how to invoke it.

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

  Parameters5/5

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

  Schema coverage is 100%, but the description adds substantial value beyond the schema. It provides concrete OData syntax examples for filter, select, orderby, and expand, explains the significance of top's default, and clarifies how parameters interact (e.g., company scoping exceptions).

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

  Purpose5/5

  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: 'Reads records from Business Central in bulk using the Standard API v2.0 (OData/REST on port 7048).' It clearly differentiates bc_query from siblings by explicitly contrasting it with bc_open_page + bc_read_data for bulk reads, and it lists concrete use cases like fetching sales orders or customers.

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

  Usage Guidelines5/5

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

  The description has explicit 'When to use' and 'When NOT to use' sections. It names specific alternatives (bc_open_page + bc_execute_action for UI flows, bc_write_data and bc_execute_action for mutations, UI WebSocket tools for custom entities) and explains why bc_query is preferred for server-side filtered bulk reads.

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

• bc_wizard_navigateA
  5/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It reveals how button identification works (by icon resource, not SystemAction/caption, enabling localised wizards), what the response contains (fields, availableNav, closed flag), and the side effect that the wizard closes itself on finish/cancel and the pageContextId becomes invalid. These are valuable behavioral details beyond basic operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is appropriately structured: purpose first, then usage guidance, behavioral notes, a workflow, exclusions, and an example. Every sentence adds practical value, and the length is justified given the tool's complexity. It is not verbose or repetitive—each section earns its place.

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

  Completeness5/5

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

  Given that there is no output schema and no annotations, the description delivers a complete picture: when to use the tool, how it behaves internally, what the response exposes, what happens after finish/cancel, and a concrete workflow. The tool is stateful and wizard-specific, and the description adequately covers its lifecycle and edge cases.

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

  Parameters5/5

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

  Although schema coverage is 100%, the description adds meaning beyond the schema. It explains that pageContextId is 'returned by bc_open_page' and elaborates on each action value ('next' advances, 'back' returns, 'finish' completes, 'cancel' aborts). The example further clarifies parameter usage. This contextualizes the parameters effectively.

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

  Purpose5/5

  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: 'Drive a Business Central NavigatePage / wizard by semantic step.' It clearly distinguishes this tool from siblings by scoping it to wizards (NavigatePage) and explicitly excluding non-wizard pages (which should use bc_execute_action). This makes the tool's purpose unambiguous.

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

  Usage Guidelines5/5

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

  The description provides explicit when-to-use guidance: 'Use after bc_open_page on a page whose response has isModal: true and pageType: "NavigatePage".' It also states when not to use it: 'Do NOT use this for non-wizard pages -- use bc_execute_action instead.' A typical workflow is outlined, and a warning about not calling 'next' past the last step is given. This fully covers usage context and alternatives.

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