Server Quality Checklist

Tool Scores

• execute_actionA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description bears full responsibility for disclosing behavioral traits. It mentions the bound/unbound distinction but does not disclose potential side effects, permission requirements, or return behavior. For an 'execute' tool, the lack of transparency about consequences is a significant gap.

  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 two sentences long, front-loaded with the core purpose, and provides examples and a bound-action note without redundancy or wasted words.

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

  Completeness3/5

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

  The tool has moderate complexity with four parameters and no output schema. The description covers the key concept of bound vs unbound actions and gives guidance, but omits expected return format and error/edge-case behavior, which is a notable gap given the lack of annotations.

  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?

  Schema description coverage is 100%, making the baseline 3. The description adds examples of action names and clarifies bound action parameters, but does not materially enhance understanding beyond the schema descriptions.

  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 executes Dataverse unbound or bound actions, with specific examples (WinOpportunity, SendEmail) and a distinction between bound and unbound. This uniquely positions it against sibling CRUD tools.

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

  Usage Guidelines4/5

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

  The description provides clear examples of when to use the tool (custom actions, standard actions like WinOpportunity) and explicitly notes that bound actions require boundTableName and boundRecordId. However, it does not explicitly contrast with alternatives like create_record or update_record.

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

• query_recordsA
  3.7/5.0
  Behavior3/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 does disclose pagination behavior by explaining hasNextPage and nextLink, which is useful. However, it does not explicitly state that this is a read-only operation, nor does it mention any permissions prerequisites or rate limits. The opaque query behavior is not fully disclosed.

  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 two sentences long and front-loaded with the core purpose. Every sentence earns its place: the first states the function, the second provides essential pagination guidance. No fluff or redundancy.

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

  Completeness3/5

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

  The tool has medium complexity with 7 parameters and no output schema. The description covers the main query capabilities and pagination, but it does not explain the return format (e.g., an array of records) or provide guidance on when to use this tool versus sibling query tools. It is adequate for a straightforward query tool but lacks deeper contextual completeness.

  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?

  Schema description coverage is 100%, so the schema already documents all 7 parameters clearly. The description adds minimal value beyond the schema by listing supported OData features ($filter, $select, etc.) and mentioning nextLink for pagination, but this largely echoes what the schema already states. No new semantic information is introduced.

  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 'Query records from a Dataverse table using OData', which is a specific verb and resource. It distinguishes itself from sibling tools like execute_fetchxml by explicitly mentioning the OData query method, and from get_record by indicating it returns multiple records via OData.

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

  Usage Guidelines3/5

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

  The description implies usage through its OData focus and mentions supported features, but it does not explicitly state when to use this tool versus alternatives like execute_fetchxml or list_tables. There is no 'use this instead of...' guidance, so the usage context is implied rather than explicit.

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

• create_recordA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden. It clearly states the action and return value, but doesn't disclose details like authorization needs, error behavior, or mutation implications beyond the verb 'create'. Adequate for a straightforward create operation, 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.

  Conciseness5/5

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

  Two sentences, front-loaded with the action and return value, followed by a concise usage tip. Every sentence earns its place with no redundancy.

  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 simple create tool with a rich schema and no output schema, the description covers the main points: what it does, what it returns, and the prerequisite discovery step. It could mention error conditions or authorization, but the coverage is sufficient for an agent to understand and invoke it correctly.

  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?

  Schema coverage is 100% and both parameters have detailed descriptions, including the OData bind syntax for lookup fields. The description reinforces using describe_table but doesn't add significant new semantics beyond the schema, so baseline 3 is appropriate.

  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 'Create a single record in a Dataverse table' with a specific verb and resource, and notes it returns the GUID. This clearly distinguishes it from siblings like bulk_create_records, update_record, and upsert_record.

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

  Usage Guidelines4/5

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

  The description gives explicit prerequisite guidance: 'Use describe_table first to discover correct field names and types.' It also implies single-record use, though it doesn't explicitly contrast with bulk_create_records. The guidance is clear and actionable.

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

• execute_fetchxmlA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description must carry the burden of behavioral disclosure. It adds useful context about FetchXML's capabilities but does not mention read-only nature, pagination (despite nextLink), response format, or potential performance costs. It is not misleading but is incomplete.

  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 two sentences, front-loaded with the action, and every sentence earns its place: the first states the purpose, the second explains the value proposition and usage context. No redundancy or filler.

  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 tool's purpose and high-level usage are clear, and the schema fully documents parameters. However, the absence of details on output format or pagination (despite the nextLink parameter) makes it slightly incomplete for a complex analytical query tool. Overall, it is adequate but not exhaustive.

  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?

  Schema coverage is 100%, so the baseline is 3. The description adds context about the query language's features, which relates to fetchXml, but does not significantly elaborate on parameter meanings beyond what the schema provides. The schema already includes descriptions and an example.

  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 'Execute a FetchXML query against Dataverse' and distinguishes the tool from OData-based query_records by highlighting FetchXML's support for aggregate functions, linked entities, and grouping. This is a specific verb+resource with clear scope.

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

  Usage Guidelines4/5

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

  It explicitly says to use this for 'complex reporting or analytical queries' and notes that FetchXML supports constructs 'that cannot be expressed in OData', implying when to prefer it over alternatives. It doesn't give explicit exclusions, but the guidance is clear and context-rich.

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

• get_recordA
  4/5.0
  Behavior3/5

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

  Without annotations, the description must stand alone. It indicates a read operation via 'Fetch' and provides usage tips, but it does not disclose behavior for record-not-found, permissions, or potential errors. The guidance on select/expand adds some transparency, but not comprehensive.

  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?

  Two sentences, direct, with the core purpose front-loaded and parameter guidance in a second sentence. No extraneous text.

  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 simple fetch-by-ID tool with a fully described input schema, the description sufficiently conveys what the tool does and how to shape results. It doesn't mention return format but the purpose implies it.

  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?

  Schema descriptions cover all 4 parameters with examples, so the description adds little beyond repeating the existence of select and expand. Baseline 3 is appropriate.

  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 uses the specific verb 'Fetch' and identifies the resource as 'a single Dataverse record' with a GUID, clearly distinguishing it from sibling tools like query_records which fetch multiple records.

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

  Usage Guidelines4/5

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

  The description implies usage when you have a record GUID and need one record, and it offers guidance on select/expand for shaping output. However, it does not explicitly state when to prefer this over query_records or other alternatives, so it stops short of a 5.

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

• update_recordA
  4/5.0
  Behavior4/5

  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 PATCH semantics (only provided fields change) and the error behavior on missing records. This is meaningful behavioral context beyond a simple 'update' statement, though it does not mention permissions or return values.

  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 concise, consisting of two sentences with front-loaded key information: the action, the resource, the semantics, and the failure condition. No wasted words.

  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 the core behavior (patch, existence check) and is appropriate for the tool's complexity. There is no output schema, so return values are not described, but this is a minor omission given the simple update operation and complete parameter schema.

  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 input schema already provides descriptions for all three parameters, including clear explanation of the 'data' parameter. The tool description reinforces the patch semantics but does not add new parameter-specific meaning beyond the schema, so the baseline of 3 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 updates specific fields on an existing Dataverse record, specifies PATCH semantics, and distinguishes from siblings like create_record and delete_record by emphasizing partial updates on existing records.

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

  Usage Guidelines3/5

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

  The description implies usage for existing records via 'existing Dataverse record' and the explicit failure condition if the record does not exist, but it does not directly mention alternatives such as upsert_record for create-or-update scenarios. Guidance is implied rather than explicit.

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

• describe_tableA
  4.1/5.0
  Behavior4/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 handles it well by disclosing caching behavior (5 minutes) and explaining how to handle Lookup fields with @odata.bind syntax. This adds valuable context beyond the basic fetch operation.

  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 front-loaded with the core purpose and every sentence contributes meaning. It is somewhat lengthy due to the Lookup syntax explanation, but this detail is useful and not wasteful.

  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 simple one-parameter tool with no output schema or annotations, the description covers the operation, usage context, key return contents, and caching. It could be more explicit about the overall response shape, but it is largely complete for agent use.

  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 input schema already fully documents the single parameter (tableName) with 100% coverage, and the description adds no additional parameter-level detail, meeting the baseline for acceptable schema coverage.

  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 fetches the full metadata schema for a Dataverse table, specifying columns and relationship types. This distinguishes it from sibling tools like get_record (data retrieval) and list_tables (table listing).

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

  Usage Guidelines4/5

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

  It explicitly instructs to ALWAYS call this before creating or updating records, providing strong contextual usage. However, it does not mention when not to use it or name alternatives, stopping 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.

• disassociate_recordsA
  4.1/5.0
  Behavior3/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 disclosing behavior. It explains the conditional use of relatedRecordId, which is useful, but does not disclose whether the operation is reversible, whether it fails if the relationship does not exist, or any permissions/error behavior. It also does not mention that the records themselves are not deleted, which is an important behavioral distinction.

  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 two sentences, front-loaded with the primary purpose, and includes only essential conditional details. Every sentence adds value; no redundancy or filler.

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

  Completeness3/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 and no annotations, so the description must cover return values and error conditions. It does not mention what the response looks like or what happens if the relationship is not found. The core usage is covered, but missing response/error context makes it only partially complete.

  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% with descriptions for all four parameters, so the schema already provides baseline clarity. The description adds valuable semantics by explaining the role of relatedRecordId is conditional based on navigation property type, which goes beyond the schema's static description. This clarifies exactly when the parameter is required or must be omitted.

  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 action: 'Remove a relationship link between two Dataverse records.' This specifies the verb (remove), the resource (relationship link between records), and distinguishes from deleting records or adding relationships. It also differentiates the behavior for collection vs. single-valued navigation, making 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 Guidelines4/5

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

  The description provides explicit instructions on when to include or omit relatedRecordId based on navigation property type ('For collection navigation properties... For single-valued... omit'). This is strong usage guidance for how to invoke the tool correctly. It does not explicitly state alternatives or when not to use this tool vs. delete_record, but the context of removing a link (not a record) is implied.

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

• associate_recordsA
  4.2/5.0
  Behavior3/5

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

  The description discloses the core action and clarifies the distinction between single-valued (N:1) and collection-valued (1:N) navigation properties, which is useful. However, with no annotations provided, it doesn't disclose side effects, idempotency, error conditions, or what happens if the relationship already exists, leaving the agent with incomplete behavioral expectations.

  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?

  Two sentences, directly front-loaded with the action, and includes the key parameter guidance. No waste; every sentence contributes.

  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 and schema together cover all six parameters thoroughly, and the description explains the primary complexity (isSingleValued). However, with no annotations or output schema, the description could add more context about what happens on conflict or how errors are signaled, so it's not a perfect 5.

  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 enriches the isSingleValued parameter by explaining it in terms of N:1 lookup properties vs 1:N collection navigation, which adds semantic value beyond the schema's terse description. Other parameters are well-covered by the schema.

  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 'Create a relationship link between two Dataverse records via a navigation property,' which identifies the verb, resource, and mechanism. It distinguishes from sibling tools like disassociate_records, which handles the opposite action, and create_record, which creates a new record.

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

  Usage Guidelines4/5

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

  Provides clear context for when to use: to associate records via a navigation property. It explains how to choose isSingleValued based on relationship type. However, it does not explicitly mention alternatives such as disassociate_records for removing links, so it falls 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.

• batch_transactionA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It clearly discloses the most critical behavior: atomicity and rollback of all operations if any fails. This goes beyond the schema by explaining the semantic guarantee, though it doesn't mention error response format or permission requirements.

  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?

  Two sentences convey the core purpose, the key behavioral guarantee, and the supported operation types. No filler or redundancy—every sentence earns its place.

  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?

  Given the lack of an output schema and the moderate complexity of a batch operation, the description covers the crucial aspects: atomicity, mixed operations, and rollback. Combined with a well-documented input schema, this is largely sufficient, though it could briefly mention what the response contains or how errors are surfaced.

  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 provides 100% coverage of the single 'operations' parameter, including a description of ordered list and atomicity. The tool description adds no additional parameter-level detail beyond what the schema states, so the baseline score of 3 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's function: execute multiple Dataverse write operations atomically in a single batch. It specifies the resource (write operations) and scope (batch), and differentiates itself from sibling bulk tools by emphasizing all-or-nothing semantics and support for mixed operation types.

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

  Usage Guidelines4/5

  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 atomicity across a mix of create/update/delete/upsert operations on different tables. It doesn't explicitly name sibling alternatives like bulk_create_records, but the emphasis on atomicity and mixed operations provides clear usage context without exclusions.

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

• bulk_create_recordsA
  4.2/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 of behavioral disclosure. It reveals the batch operation, the 1000-record limit, chunk size, and per-record success/failure tracking with partial success support — key traits that affect how the agent should handle results. It does not cover authentication or side effects, but those are less critical for a create 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 two sentences that front-load the purpose and immediately provide important constraints. Every sentence earns its place, with no fluff or repetition of schema details.

  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 addresses the key complexities of a bulk operation: limits, chunking, and partial failure behavior. It does not describe the response format or how to access per-record results, but since there is no output schema, this is less critical. Overall, it is sufficiently complete for an agent to decide whether to invoke this tool.

  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 input schema provides descriptions for both parameters (tableName and items) with 100% coverage. The description adds no additional parameter-specific meaning beyond 'records' and 'Dataverse table,' which are already in the schema. 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.

  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: 'Create multiple records in a single OData $batch operation.' It uses a specific verb ('Create') and resource ('multiple records'), and distinguishes itself from siblings like create_record (single) and bulk_update_records/bulk_delete_records by emphasizing the batch nature.

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

  Usage Guidelines4/5

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

  The description implies usage for bulk creation with explicit constraints (up to 1000 records, chunked in 100) and mentions partial success, which is critical for deciding when to use it. However, it does not explicitly name alternatives or state 'use create_record for a single record,' leaving room for clearer guidance.

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

• bulk_update_recordsA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description discloses key behavioral traits: chunking, partial success with per-record tracking, and PATCH semantics. This goes beyond the schema and provides significant context for the agent, though it doesn't describe the exact response format or error behavior.

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

  Conciseness5/5

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

  The description is three concise sentences, each containing distinct valuable information: purpose, batch limits, and semantics/error tracking. No redundant wording, and the most important constraint is front-loaded.

  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 tool is relatively complex with batch processing and partial success, but the description covers the essential aspects for an agent: limit, chunking, update semantics, and per-record tracking. Lack of an output schema means it could further specify the response shape, but current coverage is strong.

  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?

  Schema coverage is 100%, so the description doesn't need to add parameter-level detail. It does reinforce the requirement of recordId and data objects and clarifies PATCH semantics, but this is largely already present in the schema descriptions. Baseline 3 is appropriate.

  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 updates multiple records via a single OData $batch operation, with the verb 'Update' and resource 'records'. It distinguishes itself from sibling bulk_create_records and bulk_delete_records, and from single-record update_record, making 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 Guidelines4/5

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

  The description conveys the batch context and constraints (up to 1000 records, chunks of 100, PATCH semantics), which implicitly guides when to use this over single-record updates. However, it does not explicitly mention alternatives or exclusion cases, such as when to use bulk_create_records or batch_transaction instead.

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

• get_option_set_valuesA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses the return type (integer code + label) and that it returns every option. However, it does not mention edge cases such as conflicting parameters, empty results, or required permissions, leaving some behavioral ambiguity.

  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?

  Two sentences, front-loaded with the core purpose, and every sentence adds value. No redundant information or filler.

  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 simple lookup tool with no output schema and three optional params, the description covers purpose, parameter selection, and return value. It is missing guidance on what happens if no params or conflicting params are provided, but this is a minor gap given the tool's simplicity.

  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%, with all three parameters well described. The description adds semantic value beyond the schema by explaining the local vs. global distinction and reinforcing which parameter combination to use in which scenario.

  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 fetches all option values for a Dataverse choice column or global option set. It distinguishes local vs. global usage and is distinct from sibling CRUD/query/metadata tools.

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

  Usage Guidelines4/5

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

  It explicitly tells when to use tableName+attributeName (local choice/picklist/status/state) vs. optionSetName (global option set), and mentions the values are useful for filtering/writing. It lacks explicit 'don't use' alternatives but gives clear context.

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

• list_tablesA
  4.2/5.0
  Behavior4/5

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

  No annotations exist, so the description carries the transparency burden. It discloses a meaningful behavioral trait: 'Results are cached for 5 minutes.' The verb 'List' implies a read-only operation, but it doesn't describe output shape or pagination; still, the caching note adds useful 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?

  Three concise sentences that are front-loaded with the core purpose and parameter usage, with no filler or redundant detail.

  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 tool is a relatively simple listing operation, and all three parameters are documented in the schema. The description adds filtering guidance and caching behavior. It does not specify the return format, but given the simplicity and lack of output schema, the description is sufficiently complete 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.

  Parameters3/5

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

  Input schema description coverage is 100%, and the description repeats the meaning of customOnly and nameContains already present in the schema. It does not add new parameter-level detail beyond the schema, so the baseline of 3 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 opens with 'List all available Dataverse tables (entities)', a specific verb+resource pair that clearly distinguishes this from sibling describe_table, which describes a single table. The mention of 'available' clarifies the tool returns the full set of tables.

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

  Usage Guidelines4/5

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

  It provides actionable usage guidance by explicitly mentioning how to filter results: 'Use customOnly=true to see only custom tables. Use nameContains to search by name substring.' This gives clear context for invocation, though it does not explicitly name alternative sibling tools or state when not to use this tool.

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

• upsert_recordA
  4.2/5.0
  Behavior3/5

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

  The description discloses mode-specific failure behaviors and PUT semantics, which is valuable given no annotations are present. But it does not mention permissions, idempotency beyond 'PUT semantics', or response contents. For a mutation tool with zero annotation support, this is moderate transparency.

  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 concise, front-loaded, and free of fluff. It states the core purpose in one sentence and then explains all modes in a follow-up, with every clause contributing meaningful information.

  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?

  Given the tool's complexity (4 params, nested data object, no annotations, no output schema), the description covers main behavior and mode semantics thoroughly. The schema's data parameter already provides detailed field formatting guidance, so the description is sufficient for correct invocation, though it omits return values and auth prerequisites.

  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 baseline is 3. The description adds value by clarifying the meaning of each mode (e.g., 'createOnly' fails if exists) beyond the schema's brief 'Upsert behavior' note. It also reinforces that recordId must be a GUID, aligning with the schema's uuid format.

  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: 'Create or update a Dataverse record with a known GUID (PUT semantics).' This clearly distinguishes from sibling tools like create_record (no GUID needed) and update_record (requires existing record). It also explains the three modes, making 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 Guidelines4/5

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

  The description provides clear context: use with a known GUID, and explicitly explains when each mode is appropriate ('createOnly' fails if exists, 'updateOnly' fails if not). However, it does not directly name sibling tools as alternatives for non-GUID scenarios, so it lacks explicit exclusions.

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

• delete_recordA
  4.3/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It explicitly states 'This is irreversible,' disclosing the most critical behavioral trait for a deletion tool. It does not mention error handling or prerequisites, but the irreversible warning is substantive and informative.

  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 two sentences, front-loaded with the action and resource, and every word contributes meaning. 'This is irreversible' is a necessary warning 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 simple single-record deletion tool, the description fully covers the purpose, scope, and the key side effect (irreversibility). With no output schema, there is no need to describe return values. The sibling context already includes bulk_delete_records, so the 'single' qualifier provides sufficient contextual separation.

  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?

  Schema coverage is 100%, and the description adds no additional meaning beyond what the schema already provides for recordId and tableName. The schema includes UUID format and examples, so the description is not needed for parameter clarification.

  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 uses a specific verb ('Delete') and clearly identifies the resource ('a single Dataverse record by its GUID'). It explicitly states scope ('single'), which differentiates it from sibling bulk_delete_records. This is a clear and precise purpose statement.

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

  Usage Guidelines4/5

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

  The word 'single' implies this tool is for one record at a time, providing context for when to use it vs. bulk operations. However, it does not explicitly name alternatives like bulk_delete_records or state when not to use it, so it's 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.

• bulk_delete_recordsA
  4.4/5.0
  Behavior4/5

  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 destructive nature ('Delete'), the batch mechanism, a hard limit (1000 GUIDs), and per-record success/failure tracking with partial success. This adds meaningful behavioral context beyond the raw name and 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 three concise sentences, each adding distinct value: the purpose, the API limit, and the partial success behavior. No fluff or repetition; it is fully front-loaded with the core action.

  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 tool with no output schema, the description adequately covers the main aspects: operation, batch size, and per-record result handling. It implies the return format (per-record success/failure) but does not explicitly state the response structure, leaving a minor gap for a moderately complex operation.

  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 both parameters (recordIds and tableName). The description adds context about the batch operation and partial success, which clarifies how recordIds is processed and what outcome to expect, enhancing the schema's basic descriptions.

  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 it deletes multiple records in a single OData $batch operation, using a specific verb 'Delete' and defining the scope ('multiple records', 'single OData $batch operation'). This distinguishes it from siblings like delete_record (single) and bulk_create_records/bulk_update_records.

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

  Usage Guidelines4/5

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

  The description implies usage for bulk deletion when multiple records need to be removed efficiently, with explicit limits (1000 GUIDs per call) and partial success support. However, it does not explicitly state when NOT to use it or directly compare to alternatives like delete_record.

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

• refresh_metadata_cacheA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden of disclosing behavior. It explains the immediate effect (next calls to describe_table or list_tables get fresh data), which is the core behavioral trait. It does not mention potential side effects like global cache clearing, but that is covered in the parameter schema. The description adds useful context beyond the schema, such as the trigger condition (schema changes).

  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 two sentences, front-loaded with the main action and then the usage context. Every word earns its place, with no fluff or redundant details.

  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?

  This is a simple tool with one optional parameter, fully documented in the schema. The description covers purpose, effect, and when to use it. There is no output schema needed for a cache invalidation operation, and the description provides enough context for an agent to decide when and how to invoke it.

  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?

  Schema coverage is 100%: the sole parameter tableName has a clear description ('Specific table to invalidate. Omit to clear ALL cached metadata.'). The tool description itself does not add further parameter-level meaning, so the baseline score of 3 is appropriate.

  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: invalidating cached table metadata to force fresh data on the next call to describe_table or list_tables. It uses a specific verb (invalidate) and resource (cached table metadata), and explicitly distinguishes its scope from siblings by naming the affected read operations.

  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 guidance on when to use the tool: 'Use this after schema changes (new fields, new relationships) in your Dataverse environment.' This provides a clear, actionable context for the agent, even though it does not mention alternatives (there are none for this specific cache invalidation purpose).

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

• sign_outA
  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 full transparency burden. It discloses that it clears cached Microsoft credentials and that the next Dataverse operation will require a fresh login. This covers the key side effect, though it doesn't mention idempotency or return behavior.

  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?

  Two concise sentences provide complete information without redundancy. Every part contributes to understanding the tool's function and consequence.

  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 zero-parameter tool with no output schema and no annotations, the description is sufficient. It explains the operation and its future impact (fresh login), making it complete for an agent to decide invocation.

  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 no parameters, so the empty schema is fully described by the description. Baseline 4 applies since no parameter documentation is needed.

  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 action ('Sign out') and the resource ('cached Microsoft credentials'), with an additional consequence that a fresh login will be triggered. This is specific and leaves no ambiguity about the tool's purpose, distinguishing it from other tools like whoami.

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

  Usage Guidelines4/5

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

  The description implies its usage context—when you need to sign out and clear credentials to force re-authentication. It doesn't list explicit alternatives, but there are no directly comparable sibling tools, so clear context is provided. However, it stops short of explicit when-to/not-to-use instructions.

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

• whoamiA
  4.7/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. It correctly implies a read-only operation ('Show') and adds context about verifying authentication status. It does not explicitly describe the return format or behavior when not signed in, but this is acceptable for such a simple 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?

  Two short, front-loaded sentences. The first states the core function, the second gives a practical use case. No wasted words.

  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 no-parameter, no-output-schema tool that simply identifies the current account, the description fully covers what it does and when to use it. No significant gaps remain.

  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, so the schema is trivially complete. The description adds no parameter details, but none are needed; baseline 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 uses the specific verb 'Show' and names a concrete resource: 'currently signed-in Microsoft account.' It clearly distinguishes this from sibling tools, which all handle data operations or sign-out.

  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?

  Explicitly states when to use: 'Use this to verify authentication status before running Dataverse operations.' This provides clear context and a practical use case, even without naming alternatives.

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