Server Quality Checklist

Tool Scores

• ucontrol_read_umap_review_dataC
  2.4/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds no behavioral context beyond what the annotations provide, such as return format, pagination, or rate limits. It does not contradict annotations, but it also does not complement them.

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

  Conciseness3/5

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

  The description is extremely short and front-loaded, which is appropriate for a zero-parameter tool. However, it is so sparse that it reads as a label rather than an explanation, providing minimal value to an agent.

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

  Completeness2/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 and many sibling tools with similar names, the description is incomplete. It does not explain what review data contains, whether it returns a list or single entity, or how it relates to other uMap data tools. An agent would likely need to inspect other sources to understand the tool's purpose.

  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 there is nothing to document. The description does not need to explain parameter meanings. The baseline for zero-parameter tools is 4, and the description does not detract from that.

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

  Purpose2/5

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

  The description 'uMap API: read review data' directly restates the tool name and title without adding any new information. It identifies the action (read) and resource (review data) but does not clarify what review data refers to or differentiate from sibling tools beyond the name itself.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus any of the many sibling ucontrol_read_umap_* tools. It does not mention any prerequisites, alternatives, or use cases.

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

• ucontrol_read_umap_servicesC
  2.4/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds no extra behavioral context such as pagination, ordering, or response format. It does not contradict the annotations, but it contributes nothing beyond them.

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

  Conciseness3/5

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

  The description is only one short sentence and is arguably concise, but it is under-specified. The phrase 'list services' is the core, but the lack of any additional detail makes it less useful as a standalone explanation.

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

  Completeness2/5

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

  For a simple list tool, the description is minimal but incomplete. It does not mention that results may be paginated (despite page/size parameters), what a 'service' is, or what the response looks like. Given the presence of many sibling tools, this description does not provide enough context for reliable selection.

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

  Parameters1/5

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

  Input schema has two parameters (page, size) with no descriptions (0% coverage). The description does not mention pagination or any parameter semantics, so it fails to compensate for the lack of documentation. An agent would not know how to use page/size effectively.

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

  Purpose4/5

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

  The description 'uMap API: list services' clearly states the action (list) and the resource (services), making the purpose understandable. It distinguishes from sibling tools that list other resources (e.g., models, components), though it does not elaborate on what constitutes a 'service'.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus siblings or any context for selection. It simply states the action without mentioning alternatives, prerequisites, or typical use cases.

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

• ucontrol_read_umap_modelsC
  2.7/5.0
  Behavior2/5

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

  The description only repeats the read-only nature ('list') which is already covered by the annotations. It adds no new behavioral traits like pagination behavior, return format, or scoping constraints. No contradiction with annotations.

  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 a single concise sentence with no filler. It is appropriately sized for the simplicity of the operation, though it sacrifices completeness (see other dimensions).

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

  Completeness2/5

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

  With no output schema and sparse description, the agent has no idea what the response structure is, what pagination entails, or how this relates to sibling tools. The description is too brief to be complete for a tool with optional parameters.

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

  Parameters1/5

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

  The schema has 0% description coverage for its two parameters (page, size), and the description does not mention them at all. The agent receives no explanation of what these parameters mean or how to use them, leaving a gap the description should have filled.

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

  Purpose4/5

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

  The description states a specific action ('list') and resource ('models'), making the tool's purpose clear. It is distinct from siblings like 'read_umap_model_details' by indicating a collection operation, though it does not explicitly reference alternatives.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives such as 'ucontrol_read_umap_model_details' or other read tools. The description does not mention any context or exclusions.

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

• ucontrol_read_umap_model_cisC
  2.8/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the read-only and idempotent behavior is known. The description adds no extra behavioral context such as authentication needs, rate limits, pagination, or return format, providing minimal value beyond the annotations.

  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?

  A single, focused sentence with no redundancy or fluff. It immediately conveys the core operation and resource, making it highly concise and well-structured.

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

  Completeness2/5

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

  The description is too sparse for confident tool selection. It lacks parameter meanings, relationship semantics (what 'linked' means), and differentiation from the many sibling tools. Annotations cover safety but not domain context, leaving the agent with limited understanding.

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

  Parameters2/5

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

  The schema has zero descriptions for its two required parameters, and the description does not compensate. While uMapId is implicitly the model identifier, the meaning of 'kind' is entirely unexplained, and no enums or value hints are provided.

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

  Purpose4/5

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

  The description clearly states the action (list) and resource (CIs linked to a uMap model), which is distinct from sibling tools like ucontrol_read_umap_models that list models themselves. However, it does not explicitly differentiate from closely related tools such as ucontrol_read_umap_model_details, so it lacks explicit 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 Guidelines2/5

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

  No guidance is provided on when to use this tool versus the many sibling read tools. The description does not mention alternatives, prerequisites, or typical use cases, leaving the agent to infer appropriate usage.

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

• ucontrol_read_umap_bmc_appliancesB
  3.1/5.0
  Behavior2/5

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

  The description adds no behavioral detail beyond what the annotations already indicate (read-only, idempotent, open world). It does not mention pagination, filtering, output format, or any limitations, so the agent gains no extra 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 a single, direct sentence with no redundant words. It is appropriately sized for a tool with no parameters and minimal information needs.

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

  Completeness2/5

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

  The description is too sparse to be fully self-contained. There is no output schema and no elaboration on what a 'BMC appliance' is, what fields the list returns, or how this tool relates to the numerous sibling tools. It leaves the agent guessing about the response structure and scope.

  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 has zero parameters, and the schema description coverage is high (100% trivially). Per the rubric, 0 parameters gives a baseline of 4. The description does not need to add parameter meaning.

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

  Purpose4/5

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

  The description clearly states the tool lists BMC appliances via the uMap API, using a specific verb ('list') and resource. However, it does not differentiate this from the many similar sibling tools that also read uMap data.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool instead of alternatives like ucontrol_read_umap_models or ucontrol_read_umap_services. There is no context about use cases, prerequisites, or exclusions.

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

• ucontrol_read_umap_componentsB
  3.1/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds no behavioral context beyond the bare action, such as what data is returned, pagination, or implications of the 'open world' hint. It does not contradict annotations, but it also does not add value beyond them.

  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 one short sentence, immediately stating the action and scope. It is efficiently front-loaded with no filler or redundancy. For a zero-parameter list operation, this level of brevity is appropriate and earns its place.

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

  Completeness2/5

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

  Given the simple nature of the tool (no params, strong annotations), one might expect a minimal description to suffice. However, the term 'components' is vague, and with no output schema, the agent is left without any indication of what the returned list contains, how it is structured, or how this relates to sibling uMap entities. The description is too sparse to fully support correct usage.

  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 input schema is empty. According to the rubric, a baseline of 4 is appropriate when there are no params to describe. The description does not need to elaborate on parameter semantics, and it correctly avoids adding irrelevant information.

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

  Purpose4/5

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

  The description clearly states the action ('list components') and the resource ('uMap API'), identifying the tool's purpose. It is not a mere tautology, but it does not differentiate 'components' from the many sibling uMap read tools, leaving some ambiguity about what exactly constitutes a component.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no mention of typical use cases. An agent receives no information about when to select this over the many other ucontrol_read_umap_* tools.

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

• ucontrol_read_umap_dependenciesB
  3.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds minimal context (it's an API listing) but does not disclose return format, pagination, or any behavioral specifics. It does not contradict the annotations.

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

  Conciseness2/5

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

  The description is extremely short, but the 'uMap API:' prefix is redundant with the tool name, and 'list dependencies' is under-speccified about what the dependencies are. It is concise but at the cost of clarity, leaving it incomplete rather than optimally compact.

  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?

  Given the tool has no parameters and no output schema, the description does not need to explain complex inputs or returns. However, the meaning of 'dependencies' within the uMAP context is ambiguous, and there is no information about what will be returned, so the description is minimally viable but has clear gaps.

  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 has zero parameters, so the baseline for parameter semantics is 4. The description adds no parameter information, but none is needed. No additional explanation is required.

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

  Purpose4/5

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

  The description uses the verb 'list' and identifies the resource as 'dependencies,' providing a basic sense of the operation. However, it does not clarify what kind of dependencies (e.g., model dependencies, service dependencies) or how this differs from the many sibling uMAP read tools, so it lacks 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 Guidelines2/5

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

  No guidance is provided regarding when to choose this tool over alternatives. The description only states the action with no context, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.

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

• ucontrol_read_schema_definitionsB
  3.2/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds only the phrase 'Schema API:' which is a minor contextual hint, but no behavioral details such as return format, pagination, or permissions.

  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 extremely concise, consisting of a single sentence. It front-loads the purpose but is almost too sparse, offering no additional useful detail without being verbose.

  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 no-parameter read-only list tool, the description is mostly complete. It clearly states what it lists. However, it does not describe the return value structure, which could matter for an agent expecting a specific output format. Given the simple nature, it is adequate.

  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 has zero parameters, so the description does not need to explain parameter meanings. With no parameters, the baseline of 4 is appropriate.

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

  Purpose4/5

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

  The description uses the verb 'list' with the resource 'uControl schema definitions', clearly indicating that the tool lists schema definitions. It distinguishes itself from sibling tools like ucontrol_read_schema_data and ucontrol_read_schema_ire_rules by explicitly targeting 'definitions'.

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

  Usage Guidelines2/5

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

  The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention any conditions, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.

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

• ucontrol_read_assetB
  3.3/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds no additional behavioral context beyond 'read one asset', which is already reflected in the schema's required record_identifier. No mention of response format or flag effects.

  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?

  One short sentence, front-loaded with purpose. No filler or redundancy, earning its place.

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

  Completeness2/5

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

  Despite 7 parameters and no output schema, the description offers minimal context. It does not explain the boolean flags, return values, or usage nuances. The tool is simple in concept but the description leaves too much unspecified for the agent.

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

  Parameters2/5

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

  Schema description coverage is only 14% (fields property). The description names definition and record_identifier but provides no semantic explanation of these or the five boolean flags. With 7 parameters, the description fails to compensate for the low 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 verb 'read', the resource 'asset', and the scope 'one asset by definition and record identifier'. This distinguishes it from sibling tools like ucontrol_read_assets, which reads multiple assets.

  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 use for reading a single asset, but does not explicitly mention alternatives or when-not-to-use. No guidance is provided on choosing between this and ucontrol_read_assets, making the usage partly implicit.

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

• ucontrol_read_asset_tagsB
  3.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, but the description adds meaningful context: the unusual vendor behavior of sending a JSON body on a GET request and preserving it via a Node HTTP request. This goes beyond the annotations and helps set 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?

  The description is two sentences long with no filler. The first sentence states the purpose, and the second explains a critical behavioral quirk, so every sentence earns its place.

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

  Completeness2/5

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

  While annotations cover safety, the single required parameter is undocumented and there is no output schema or return-value description. The JSON-body-on-GET quirk is noted, but without parameter semantics the tool cannot be used reliably.

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

  Parameters1/5

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

  The schema has 0% description coverage and the description does not explain the 'data' parameter or its required 'kind' and 'name' fields. Since the entire invocation hinges on this parameter, leaving it undocumented is a serious gap.

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

  Purpose4/5

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

  The description uses a specific verb and resource ('view tags for assets'), clearly indicating what the tool does. It is distinguishable from sibling tools like ucontrol_read_assets or ucontrol_read_asset, but it lacks an explicit scoping or differentiation statement.

  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 phrase 'view tags for assets' implies the tool should be used when tag information is needed, but no explicit when-to-use or alternatives are provided. With so many read sibling tools, more explicit guidance would improve selection accuracy.

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

• ucontrol_read_schema_dataB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare the tool as read-only, open-world, idempotent, and non-destructive. The description adds that it reads 'fields and metadata,' but provides no additional behavioral context such as error handling, return format, or relationship to other schema-related tools.

  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 a single, concise sentence with no filler. It efficiently communicates the core function without unnecessary detail.

  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 is simple with one parameter and rich annotations, but the description omits guidance on how to discover valid schema definition names (e.g., via sibling ucontrol_read_schema_definitions). This gap could leave an agent unsure how to populate the parameter 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?

  The single parameter 'definition' is fully documented in the input schema with an example. The tool description does not add further parameter semantics, so the baseline of 3 applies given the 100% schema coverage.

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

  Purpose4/5

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

  The description clearly states the tool reads fields and metadata for a schema definition, naming the verb and resource. It is somewhat distinct from siblings like ucontrol_read_schema_definitions, but does not explicitly differentiate.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. The description only states the operation, leaving the agent to infer usage from the tool name and sibling context.

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

• ucontrol_read_umap_sso_group_detailsB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description does not add any behavioral context beyond the annotations, such as return format or side effects, but the annotations sufficiently indicate a safe read operation. No contradiction is present.

  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 extremely concise with a single sentence and no fluff. It provides the essential resource identifier. However, it borders on under-specification, though that is more of a completeness issue than a structure issue.

  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?

  For a zero-parameter read tool with rich annotations, the description is minimally adequate. It does not mention what the 'SSO group details' contain or any potential context like authentication requirements, but the absence of parameters and the safety annotations reduce the need for additional context. Still, a more descriptive phrase would improve completeness.

  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 has zero parameters, so there is no parameter-level information needed. The description need not explain parameters, and the baseline for 0 params is 4.

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

  Purpose4/5

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

  The description clearly states a specific verb ('read') and resource ('SSO group details'), which distinguishes it from sibling tools like 'read_umap_team_details' or 'read_umap_model_details'. However, it is minimalist and does not elaborate on what 'details' includes, so it does not fully communicate the scope.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternative read tools (e.g., team details or model details). There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage solely from the resource name.

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

• ucontrol_read_umap_modelling_typesB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, which fully cover the safety and side-effect profile. The description's 'list' aligns with these hints but adds no extra behavioral context such as pagination, return format, or API-specific constraints. Since annotations carry the burden, a score of 3 is appropriate.

  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 a single concise sentence, 'uMap API: list modelling types.' It contains no filler and is front-loaded with the action. However, it is somewhat sparse and adds little beyond the tool's name, but for a simple operation this is acceptable and not overly verbose.

  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 parameterless list operation with strong annotations and no output schema, the description is minimally sufficient. It states the core function, though it does not clarify what 'modelling types' specifically includes or the return shape. Given the simplicity, this is largely complete, but a bit more detail would improve it.

  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 there is no parameter documentation burden on the description. Per the rubric, 0 params receives a baseline of 4. The description does not need to explain anything about inputs, as none exist.

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

  Purpose4/5

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

  The description 'list modelling types' clearly states the action (list) and resource (modelling types). However, it does not differentiate from sibling tools like ucontrol_read_umap_application_types or ucontrol_read_umap_service_types, which also list types. The name already conveys the resource, so it is clear but not fully distinguishing.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. The description simply states what it does without giving context, exclusions, or alternatives. Since many sibling tools list different types of entities, the absence of usage guidance leaves the agent to infer from the name alone.

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

• ucontrol_read_umap_environmentsA
  3.5/5.0
  Behavior2/5

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

  The description adds no behavioral traits beyond what annotations already provide (readOnlyHint, openWorldHint, idempotentHint, destructiveHint). No extra context such as auth requirements, pagination, rate limits, or data scope is mentioned.

  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 a single, concise sentence that is front-loaded with the operation and resource. No wasted words, ideal for quick comprehension.

  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?

  For a simple no-parameter list operation with rich annotations, the description captures the core purpose but leaves out any context about what 'environments' are, expected response shape, or any potential limitations. It's minimally sufficient but not comprehensive.

  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?

  With zero parameters in the schema, the description needs no parameter details. The baseline for 0 params is 4, and the description appropriately avoids fabricating unnecessary parameter information.

  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 ('list') and the resource ('environments'), specifying 'uMap API' for context. This distinguishes it from sibling tools that target other resources like models, services, or review data.

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

  Usage Guidelines2/5

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

  The description gives no explicit guidance on when to use this tool versus alternatives, no exclusions, and no mention of related tools. The only usage signal is the resource name itself, so context is absent.

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

• ucontrol_read_schema_ire_rulesA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat these. It adds the context that this operates on 'Schema API' and 'for an asset kind,' which is a mild scoping clarification but does not disclose any additional behavioral traits such as return format, error conditions, or rate limits.

  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 a single sentence that is front-loaded with the tool's purpose and scoped context. Every word earns its place, with 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?

  Given the single parameter, read-only annotations, and simple nature of the tool, the description is sufficient. It clearly states what is read and the scope. The lack of an output schema is not a significant gap because the tool is a simple read, and annotations cover safety. Slightly more detail about the rules' structure would push it higher, but it is complete for typical usage.

  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 fully documents the sole parameter 'kind' with description 'Asset kind,' so schema coverage is 100%. The description's phrase 'for an asset kind' adds no extra meaning beyond the schema. It does not explain allowed values, relationships, or usage nuances, but with full schema coverage the baseline 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 specifies a read operation for Identification/Reconciliation Engine rules scoped to an asset kind. The 'Schema API' prefix distinguishes it from the sibling tool ucontrol_read_umap_ire_rules, which likely targets umap instead. This is a specific verb+resource+scope that leaves little ambiguity.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. It does not mention that this reads schema-level rules while ucontrol_read_umap_ire_rules handles umap rules, nor any prerequisites or exclusions. Users must infer usage from the tool naming alone.

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

• ucontrol_read_umap_ire_rulesA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds usage context but no additional behavioral traits like return format or error handling, which is acceptable 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?

  The description is a single, front-loaded sentence with no redundant words. It efficiently conveys the tool's purpose and context.

  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 read-only tool with one required parameter and safety annotations, the description is mostly sufficient. It includes the usage timing but omits details about the return structure and the semantics of 'kind', which 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.

  Parameters2/5

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

  Schema coverage is 0%, and the description only mentions 'for a kind' without explaining what a 'kind' is or what values it can take. The description does not compensate for the lack of parameter documentation.

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

  Purpose4/5

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

  The description clearly states the action 'read IRE rules' and the target 'a kind', which is specific. The 'uMap API' prefix helps differentiate it from the similar sibling ucontrol_read_schema_ire_rules, though it doesn't explicitly name that sibling.

  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 phrase 'before populating or linking CIs' provides clear contextual timing for when this tool should be used. It doesn't mention alternatives or exclusions, but the usage scenario is well-defined.

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

• ucontrol_read_umap_team_detailsA
  3.7/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds a meaningful behavioral detail—omitting the name returns all records—which is not present in annotations. It does not cover rate limits or pagination, but the bar is lower given the annotations.

  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 extremely concise, with two short sentences that front-load the purpose and immediately cover the key parameter behavior. 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?

  For a simple read tool with one optional parameter and no output schema, the description is adequately complete. It explains the core function and the main parameter behavior, though it could mention what fields are in the details or any pagination behavior. The strong annotations reduce the need for additional safety context.

  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 provides no description for the 'name' parameter (0% coverage), so the description compensates by explaining that omitting it returns all records. This adds concrete meaning beyond the bare schema, though it does not specify the exact format or expected value of the name.

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

  Purpose4/5

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

  The description clearly states the tool reads team details from the uMap API, with a specific verb and resource. It distinguishes from siblings by naming 'team' as the resource, though it does not explicitly contrast with similar tools like ucontrol_read_umap_model_details.

  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 by defining the action, but it does not provide explicit guidance on when to choose this tool over alternatives. There are no exclusions or alternative tool references, leaving the agent to infer from the resource name.

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

• ucontrol_read_umap_model_patternsA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare the operation read-only, idempotent, and non-destructive. The description adds the scoping constraint that results are linked to a specific uMap model, which is useful context, but no additional behavioral details such as return format or pagination are provided.

  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 a single concise sentence, front-loads the API context, and contains no superfluous content.

  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 read tool with one parameter and no output schema, the description adequately conveys the operation's scope. It lacks detail on the structure of patterns, but given the domain-specific language and annotations, it is sufficiently complete for basic invocation.

  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 sole parameter uMapId is not described in the schema, and description only implicitly identifies it as the uMap model identifier via 'linked to a uMap model.' This provides some meaning but lacks format, source, or usage examples.

  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 discovery patterns linked to a uMap model, using a specific verb and resource. It distinguishes from siblings like ucontrol_read_umap_model_details by focusing on patterns.

  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 provides no explicit when-to-use or alternative guidance, but the phrasing implies it's for retrieving discovery patterns for a specific uMap model. Siblings exist but no exclusion criteria are given.

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

• ucontrol_read_umap_service_typesA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no extra behavioral context such as return format or pagination, but it does not contradict the annotations. With annotations in place, the lack of additional disclosure is acceptable.

  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 a single, concise sentence: 'uMap API: list service types.' Every word earns its place, and the structure is front-loaded with the API context.

  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 read-only listing operation, the description is sufficient for selection and invocation. It could explicitly mention the return type (e.g., 'returns a list of service types'), but given the tool's simplicity and the annotations, it is mostly 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?

  The tool has zero parameters, so the schema needs no explanation. The description adds no parameter details, but none are needed. Baseline for 0 params is 4, and the description adequately covers the operation.

  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 verb 'list' and the resource 'service types' under the uMap API. It distinguishes from sibling tools like ucontrol_read_umap_application_types and ucontrol_read_umap_modelling_types by specifying the exact resource.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus the many sibling read tools, nor any exclusions or alternatives. It simply states 'list service types' without context on selection criteria.

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

• ucontrol_read_umap_lead_accountsA
  3.9/5.0
  Behavior3/5

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

  Annotations already declare read-only, open-world, idempotent, and non-destructive behavior. The description adds no additional behavioral details such as pagination, return format, or scope of the listing, but the annotations sufficiently cover the safety profile.

  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 a single short sentence with no filler, front-loading the essential action ('list lead accounts'). It is concise and directly to the point.

  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?

  Given the extremely simple signature (no parameters) and rich annotations, the description is functionally complete but lacks any statement about the extent of data returned (e.g., all accounts, any ordering) or return value format, which prevents a higher score.

  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 has zero parameters and schema description coverage is 100% (vacuously). With no parameters, the description is not required to add parameter-level detail; 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 uses the specific verb 'list' with the resource 'lead accounts', clearly distinguishing it from sibling tools that handle different uMap entities (models, services, etc.). The verb and resource are unambiguous.

  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?

  No explicit guidance on when to use this tool versus alternatives is provided; usage is only implied by the tool name and sibling context. There is no mention of when not to use it or any alternative tools.

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

• ucontrol_read_umap_model_detailsA
  3.9/5.0
  Behavior4/5

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

  Annotations already establish safety (read-only, non-destructive, idempotent). The description adds useful behavioral context by clarifying that omitting 'name' returns all records, which goes beyond the schema and helps the agent anticipate results.

  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 a single efficient sentence of 12 words, front-loading the core purpose and adding only the most essential behavioral note. 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?

  For a simple read tool with good annotations and one optional parameter, the description covers all critical context: what it does, the parameter behavior, and the no-name behavior. It does not describe return structure, but no output schema is provided and the tool is straightforward, so this is acceptable.

  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?

  The schema has a single 'name' parameter with no description (0% coverage). The description fully compensates by stating 'Omit name to return all records', implying that providing a name returns details for that specific model. This directly clarifies the parameter's meaning and an important edge case.

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

  Purpose4/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: 'read model details' with a specific resource ('uMap API'). It also explains the optional name behavior, but it does not explicitly distinguish itself from sibling tools like 'ucontrol_read_umap_models' or 'ucontrol_read_umap_model_cis'.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It only mentions the behavior of omitting 'name', which is an operational detail, not a usage guideline. No exclusions or alternative tool references are given.

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

• ucontrol_read_umap_application_typesA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the 'uMap API' context and confirms the listing behavior, but does not provide additional behavioral details such as return format or pagination. This is consistent with annotations and adds minimal value beyond them.

  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 a single, efficiently worded sentence: 'uMap API: list model application types.' It front-loads the domain and action without any redundant phrasing or unnecessary 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?

  Given the tool's low complexity, no parameters, and rich annotations, the description sufficiently covers the action and resource. It does not describe the response format, but for a straightforward list operation this gap is minor.

  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 input schema is empty and there is nothing to document. The description correctly omits parameter details; the baseline of 4 applies because no explanation 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 uses a specific verb 'list' with a clear resource 'model application types', making the tool's function immediately obvious. It distinguishes from sibling tools like 'modelling types' or 'service types' by naming the exact kind of types.

  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 when one needs to list model application types, but provides no explicit guidance on when to choose this tool over alternatives or any prerequisites. The context is clear enough for a simple read-only list but lacks explicit exclusions or alternative recommendations.

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

• ucontrol_read_assetsA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds new behavioral context by explaining the supported filter syntax (aliases asset, geo, unit, context; operators EQUALS/NOT-EQUALS; clauses AND/OR), which goes beyond the schema. No contradiction with annotations.

  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 scope, and provides the essential filter syntax without unnecessary verbiage. Every sentence contributes value.

  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 has 10 parameters and no output schema, the description covers the core use case (reading asset records for a definition) and the filter feature. It lacks detail on pagination and the meaning of boolean info flags, but the annotations cover safety and the purpose is clear enough for a typical list operation.

  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 only 10%, so the description must compensate. It clarifies the 'definition' parameter ('for a definition') and the 'filter' parameter (syntax details). However, other parameters like limit, offset, tagInfo, unitInfo, contextInfo, inclDeleted, and locationInfo receive no explanation, leaving a significant gap.

  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 reads asset records for a definition, making the verb and resource explicit. It distinguishes itself from sibling tools like ucontrol_read_asset (which likely reads a single asset) by specifying 'for a definition' and plural '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 need to fetch multiple asset records tied to a definition, and the filter syntax is outlined with aliases and operators. However, it does not explicitly contrast with alternatives such as ucontrol_read_asset or ucontrol_read_asset_tags, so it stops short of a full 5.

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

• ucontrol_read_protocolsA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful behavior beyond annotations: the output splits read-only and write protocols, and write protocol registration is conditional on an environment variable. This provides valuable runtime context not present in structured fields.

  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, no filler. The first sentence states the action and output split; the second adds a critical conditional detail. Every word earns its place, and the information is front-loaded.

  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 parameterless read-only listing tool, the description is complete. It explains what the tool lists, how the output is organized, and under what conditions write protocols appear. No output schema exists, but the description sufficiently conveys the return structure.

  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 parameter baseline is 4. The description doesn't need to explain parameters, and the schema coverage is 100% (trivially, since there are none). The description adds no parameter-specific info, but nothing is missing.

  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 ('List') and names the resource ('uControl protocol inventory'), and clearly distinguishes it from sibling tools that read schemas or assets. It also specifies the split by read-only and write access, 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 gives clear context: it lists the protocol inventory and notes that write protocols appear only when UCONTROL_TOOL_MODE=read-write, which helps the agent understand when to expect those. However, it doesn't explicitly name alternatives or state 'use this when...' though none of the siblings compete for the same purpose.

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