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

With no annotations provided, the description carries full burden. It describes the tool's behavior: it wraps a library, generates a layer, highlights techniques, and returns a structured JSON with specific fields. It does not mention potential side effects, auth requirements, or rate limits, but it covers the core behavioral traits adequately.

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

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

The description is well-structured with a header, supported prefixes section, args list, and return format. It is front-loaded with purpose. While somewhat lengthy, every sentence adds value, and the structure aids readability.

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

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

Given the output schema is provided in the description, the return values are fully documented. The tool is moderately complex with 3 parameters and specific constraints, and the description covers all necessary aspects for an agent to use it correctly, especially compared to sibling query tools.

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

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

Although the input schema has 0% description coverage, the description text documents all three parameters (attack_id, score, domain) with types, defaults, and usage details (e.g., score assigned to all matched techniques). This adds significant meaning beyond the bare schema.

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

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

The description explicitly states 'Generate an ATT&CK Navigator layer for visualization' and explains it produces a JSON layer highlighting techniques for a given ATT&CK ID. It clearly distinguishes from sibling query tools by specifying supported ID prefixes (G, M, S, D) and explicitly excluding technique IDs (Txxxx).

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

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

The description states when to use the tool (for supported ATT&CK IDs G, M, S, D) and when not to use it (technique IDs are NOT supported). It provides clear context but does not name specific alternative tools for unsupported IDs, which would further aid decision-making.

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

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

With no annotations, the description must cover behavioral traits. It explains parameters and return format but omits details like rate limits, auth requirements, or side effects. The 'primarily ICS' hint is useful but incomplete for full transparency.

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

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

Description is well-structured with Args and Returns sections, but slightly verbose. Could be more concise, but still efficient for a 3-param tool with output schema.

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

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

Given low complexity, presence of output schema, and clear parameter explanations, the description is complete. It covers what the tool does, how to use it, and what to expect in return.

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

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

Schema description coverage is 0%, so the description compensates by explaining each parameter (domain recommendation, removing revoked, including description). The Args section adds meaningful context beyond the schema's default values.

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

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

Description clearly states it retrieves all ATT&CK assets in a domain, primarily ICS. The verb 'Get all' and resource 'assets' are specific, and it distinguishes from siblings like 'get_assets_targeted_by_technique' which is a different operation.

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

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

Description recommends 'ics' domain and clarifies the tool is for assets. While it doesn't explicitly state when not to use, the context is clear and no direct alternative exists among siblings for fetching all assets.

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

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

With no annotations provided, the description carries the full burden. It discloses the tool's behavior (retrieves campaigns, allows filtering by domain, revocation, and description inclusion) and provides the output schema. It does not mention side effects or safety, but the 'get' nature implies read-only. Overall, it is fairly transparent.

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

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

The description is well-structured with an introductory sentence, an args block, and a returns block. Every sentence adds value, and the format is efficient for an AI agent to parse. No verbosity.

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

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

Given the presence of an output schema, the description covers return values thoroughly. It explains the concept of campaigns and parameter effects. The tool's role among many sibling list tools is clear, making the description complete for its complexity.

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

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

The input schema has 0% description coverage, but the description compensates by explaining each parameter (domain, remove_revoked_deprecated, include_description) with meaningful context beyond their names and types. This fully clarifies parameter semantics.

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

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

The description clearly states 'Get all ATT&CK campaigns in a domain' and elaborates on what campaigns represent (e.g., 'intrusion events or long-running operations attributed to threat actors'), making the tool's purpose specific and distinguishable from sibling tools like get_groups or get_techniques.

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

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

The description implies usage for retrieving all campaigns in a domain, but does not explicitly state when to use this tool over alternatives (e.g., get_campaigns_attributed_to_group). The context is clear but lacks explicit exclusions or comparative guidance.

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

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

With no annotations, the description carries full burden. It describes a read operation with no side effects, and it details the return format extensively, including fields like stix_id and data_source_name. No hidden behaviors are indicated.

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

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

The description is well-structured with a summary, example explanation, Args, and Returns sections. It is moderately sized; the example of 'Process' could be slightly shorter but is still helpful.

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

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

The description fully specifies the output schema and parameter defaults. It covers the core use case well, though it could mention relationships to sibling tools like get_datacomponents_detecting_technique for better context.

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

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

Although schema description coverage is 0%, the description includes an Args section that explains each parameter (domain, remove_revoked_deprecated, include_description). This adds meaning beyond the raw schema, specifying defaults and the purpose of each parameter.

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

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

The description clearly states 'Get all ATT&CK data components in a domain' and explains what data components are with an example. It distinguishes this tool from siblings like get_all_datasources and get_all_techniques by focusing specifically on data components.

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

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

The description implies usage for retrieving all data components in a domain but does not provide explicit guidance on when to use this tool versus alternatives like get_datacomponents_detecting_technique. No when-not-to-use or exclusions are mentioned.

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

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

With no annotations provided, the description carries full burden. It discloses the read-only nature (get all), explains parameters and return format in detail. It does not mention rate limits or auth, but the behavior is transparent and no contradictions exist.

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

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

The description is structured with clear sections (purpose, explanation, args, returns) but is slightly verbose. The extra explanation of what data sources are is helpful for context. Every sentence adds value, but could be more concise.

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

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

Given the tool's simplicity (3 optional params, list return), the description is fully complete. It covers the operation, parameters, and output format in detail. The output schema is described, so no gaps remain.

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

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

Schema description coverage is 0%, but the description adds full meaning: domain values, remove_revoked_deprecated and include_description behavior, defaults. It explains each parameter's purpose completely, compensating for the lack of schema descriptions.

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

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

The description clearly states 'Get all ATT&CK data sources in a domain.' It explains what data sources are, and the tool name distinguishes it from siblings like 'get_all_datacomponents'. The purpose is specific and unambiguous.

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

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

The description implies usage when needing all data sources for a domain, but provides no explicit guidance on when to use this tool vs alternatives like 'get_all_datacomponents' or other get-all tools. No when-not-to-use or prerequisites are mentioned.

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

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

With no annotations, the description fully discloses behavior: it lists parameters and detailed return structure including fields like attack_id, name, aliases, etc. No hidden side effects mentioned, but it's a read operation.

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

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

The description is well-structured with Args and Returns sections, but the return JSON is detailed; could be slightly more concise. However, every part adds value and it's front-loaded with purpose.

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

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

Given the tool's simplicity and the presence of a complete output schema in the description, all relevant information is covered. Parameters and return values are fully documented.

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

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

Schema description coverage is 0%, but the description's Args section explains each parameter: domain with allowed values, remove_revoked_deprecated and include_description with clear semantics. The description adds full meaning beyond the bare schema.

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

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

The description clearly states 'Get all APT groups (intrusion sets) in a domain,' specifying verb, resource, and scope. It distinguishes from siblings like 'get_groups_by_alias' and 'search_groups' by implying this returns the full set.

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

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

The description does not explicitly state when to use this tool versus alternatives. It lists parameters but lacks context like 'use search_groups for specific names.' Usage is implied but not contrasted.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return format and the effect of each parameter, implying a read-only operation. The description does not explicitly state that the tool is safe and non-destructive, but the context and name suggest no side effects.

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

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

The description is concise and well-structured: a one-line purpose, a brief contextual sentence, and a clear listing of arguments and return type. Every sentence is valuable and easy to parse.

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

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

Given the tool's simplicity (3 parameters, output schema present), the description is thorough. It covers the domain options, parameter defaults, and the full return structure. The absence of annotations does not leave gaps.

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

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

The input schema has 0% description coverage, but the tool description explains each parameter (domain, remove_revoked_deprecated, include_description) with clear meaning and default values, fully compensating for the lack of schema descriptions.

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

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

The description clearly states the action ('Get all ATT&CK matrices in a domain') and specifies the resource (matrices). It explains what matrices are, distinguishing them from other sibling tools that retrieve different ATT&CK objects like techniques, groups, or software.

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

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

The description provides context on when to use the tool (to retrieve matrices for a domain) and mentions that each domain typically has one or more matrices, implying a common use case. However, it does not explicitly state when not to use the tool or suggest alternative tools for similar purposes.

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

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

No annotations provided, so description carries full burden. It thoroughly describes the return structure including optional fields and the formatted/message fields. It implicitly indicates read-only by the 'get' verb, but could explicitly state no side effects. The output schema adds transparency.

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

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

The description is well-structured with clear sections (intro, Args, Returns) and uses bullet points for the return schema. It is front-loaded with the main purpose. Minor redundancy with the definition of mitigations, but overall concise for the information provided.

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

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

Given the simple nature of the tool (listing) and the presence of an output schema, the description is fairly complete. It covers all parameters and return fields. Does not mention error handling or invalid domain behavior, but that is acceptable for a basic query tool.

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

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

Schema coverage is 0%, but the description compensates with an explicit Args section explaining each parameter's purpose and expected values (e.g., domain options, boolean effects). This adds value beyond the bare schema which only provides names and defaults.

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

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

The description clearly states it retrieves all mitigations in a domain, with a brief definition of mitigations. While it distinguishes itself from sibling tools like get_mitigations_mitigating_technique by being a broad listing, it does not explicitly contrast with other get_all_* tools.

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

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

The description implies usage for listing all mitigations but does not explicitly state when to use this tool versus more specific tools (e.g., get_mitigations_mitigating_technique). No exclusions or alternatives are mentioned.

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

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

No annotations are provided, so the description carries full burden. It explains the input parameters and the complete output structure including fields like formatted and message. It does not explicitly state read-only nature, but the function name and output description imply no side effects. The transparency is good but could be improved by noting safe behavior.

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

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

The description is well-structured with a summary, clarification of parent techniques, and separate args/returns sections. It is slightly verbose but front-loaded with the core purpose. Every sentence adds value, so it earns its length.

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

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

Given the output schema is fully described, the description covers all necessary behavioral details. The parameter explanations and output format are comprehensive for a tool with 3 simple parameters. No gaps remain for an agent to guess.

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

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

The input schema has 0% description coverage, but the description explains each parameter: domain with example values, remove_revoked_deprecated and include_description as boolean controls. Default values are also specified, adding significant semantic value beyond the schema.

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

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

The description clearly states 'Get all parent techniques (exclude subtechniques) in a given domain.' It defines parent techniques via the ATT&CK ID format (no dot), making the tool's purpose specific and distinct from siblings like get_all_techniques and get_all_subtechniques.

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

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

The description implicitly differentiates from siblings by focusing on parent techniques, but does not explicitly state when to use this tool versus alternatives. The context of sibling tools includes get_all_techniques and get_all_subtechniques, so the purpose is clear enough for an agent to select correctly.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool is an alias for get_software() and returns structured results, and includes a detailed return format. However, it does not explicitly state that the operation is read-only, safe, or any side effects, though the context suggests it is non-destructive.

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

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

The description is well-structured with a clear first line, followed by an Args and Returns section. It is slightly lengthy but every sentence adds value. Could be more concise, but it is effectively organized.

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

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

Given the tool's simplicity (3 optional parameters, no required params), the description is comprehensive. It covers purpose, parameters, and return format in detail. The output schema is provided in the Returns section, making it complete for an LLM to use.

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

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

Schema description coverage is 0%, but the description compensates fully by documenting all three parameters in an Args section: domain, remove_revoked_deprecated, and include_description, explaining their purpose and defaults.

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

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

The description clearly states 'Get all software (malware and tools) in a domain.' It specifies the resource (software) and the scope (all in a domain). It distinguishes itself from the sibling 'get_software' by noting it is an alias that returns structured results suitable for LLMs and clients.

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

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

The description implies usage for retrieving all software in a domain with optional filters, but it does not explicitly state when to use this tool over alternatives like 'get_software', 'search_software', or other sibling tools. No when-not or alternative guidance is provided.

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

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

No annotations are provided, so the description carries full burden. It describes the return structure in detail, implying a read-only, idempotent operation. It does not mention side effects, failures, or authorization, but given the tool's nature (simple retrieval), this is adequate. No contradictions.

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

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

The description is well-structured: a concise opening sentence, a clarifying example, then an Args list, and a full Returns schema. Every sentence is informative and earns its place. It is front-loaded with the core purpose.

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

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

Given the output schema provided in the description, and the simple nature of the tool (3 optional parameters, no nested objects), the description is complete. It covers all aspects: purpose, parameters, output format, and example. No missing information.

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

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

Schema coverage is 0%, so the description must compensate. It does so by listing all three parameters with clear explanations: domain is specified with allowed values ('enterprise', 'mobile', 'ics'), and the two boolean parameters are described. This adds significant value beyond the schema's defaults and titles.

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

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

The description clearly states the action ('Get all subtechniques') and the resource ('in a given ATT&CK domain'). It explains what subtechniques are and distinguishes from sibling tools like 'get_subtechniques_of_technique' and 'get_all_techniques' by specifying the scope (domain-level).

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

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

The description does not explicitly state when to use this tool versus alternatives. While the purpose is clear, it lacks guidance on when not to use it (e.g., when needing subtechniques of a specific parent technique, use 'get_subtechniques_of_technique'). Usage context is implied but not explicit.

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

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

Since no annotations are provided, the description bears the full burden. It clearly indicates a read-only operation (getting data) and describes the return structure, but does not mention authentication, rate limits, or side effects.

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

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

The description is well-structured with sections for introduction, arguments, and returns. It is front-loaded and clear, though slightly verbose with the explanation of tactics.

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

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

Given the presence of an output schema, the description provides a detailed return format and explains all parameters. It is complete for the tool's complexity.

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

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

The description includes an 'Args' section that explains both parameters (domain with examples, include_description as boolean), adding significant meaning beyond the input schema which only has defaults. This fully compensates for the 0% schema description coverage.

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

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

The description clearly states the tool's purpose: 'Get all ATT&CK tactics for a domain.' It explains what tactics are and provides examples, distinguishing it from sibling tools that retrieve tactics by matrix or technique.

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

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

The description does not explicitly state when to use this tool versus alternatives like get_tactics_by_matrix or get_tactics_by_technique. Usage is implied but lacks direct guidance or exclusions.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return structure via an output schema and describes parameter effects. However, it does not mention any behavioral traits such as permissions, rate limits, or side effects (though the tool is read-only, this is not explicitly stated).

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

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

The description is concise with a clear purpose followed by Args in a bullet-like format and a Returns block. Every sentence contributes value; no unnecessary text.

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

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

Given the tool complexity (3 parameters, many siblings, output schema provided), the description covers the essential aspects: purpose, parameters, and return structure. It lacks explicit usage guidance against siblings, but the output schema compensates for return value clarity.

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

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

With 0% schema description coverage, the description adds meaning by explaining each parameter (domain: ATT&CK domain with allowed values; remove_revoked_deprecated: exclude deprecated; include_description: include descriptions). This goes beyond the schema's names and defaults.

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

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

The description explicitly states 'Get all ATT&CK techniques for a given domain', which is a specific verb+resource combination. It includes the domain parameter and optional filters, clearly distinguishing it from sibling tools that target specific subsets like techniques by tactic or platform.

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

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

The description implies usage for retrieving all techniques for a domain, but does not explicitly mention when to use this tool versus alternatives (e.g., get_techniques_by_tactic, get_techniques_by_platform). No exclusions or when-not guidance are provided.

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

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

No annotations, so description carries full burden. Provides input and output details but lacks safety or behavior notes (e.g., read-only, rate limits). Adequate but not explicit.

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

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

Well-structured with Args and Returns sections, but slightly verbose. Could tighten some explanations without losing clarity.

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

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

Given output schema exists, description fully documents return structure: technique, count, assets with fields, formatted text, and summary. Complete for the tool's complexity.

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

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

Schema has 0% description coverage, so description explains all three parameters with brief, clear descriptions. Could add acceptable formats/values for technique_stix_id.

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

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

Description clearly states the tool gets all ICS assets targeted by a specific technique, distinguishing it from siblings like get_techniques_targeting_asset and get_all_assets.

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

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

No explicit when-to-use or when-not-to-use guidance. Context implies it's for targeted asset retrieval, but doesn't mention alternatives like get_all_assets for broader queries.

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

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

No annotations provided, so description carries burden. It explains input/output format and resolution process. For a simple lookup tool, this is sufficient, though it lacks discussion of error cases or performance.

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

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

Description is concise and well-structured with bullet points and examples. Every element serves a purpose, though some minor redundancy could be trimmed.

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

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

For a simple conversion tool with an output schema, the description covers inputs, outputs, and examples completely. No major gaps identified.

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

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

Schema coverage is 0%, but the description details both parameters (stix_id as full STIX UUID, domain with examples), adding significant meaning beyond the bare schema.

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

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

The description clearly states the tool converts STIX UUIDs to human-readable ATT&CK IDs, provides input/output examples, and distinguishes from siblings (none of which do this conversion).

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

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

The description implies usage when needing to resolve a STIX UUID to an ATT&CK ID but does not explicitly state when to use or avoid this tool versus alternatives, though context is clear.

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

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

With no annotations provided, the description fully carries the burden. It explains the purpose, parameters, and details the return structure including fields like 'group', 'count', 'campaigns', 'formatted', and 'message'. It also provides context that campaigns are specific operations attributed to a threat group. No side effects or destructive behavior are indicated, which aligns with a read operation.

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

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

The description is well-structured with an intro, Args section, and Returns section (a pseudo-output schema). It is front-loaded with the main purpose. While concise, it could be slightly shorter without losing clarity, but it earns its length by providing important parameter and return details.

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

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

Given the tool's complexity (3 parameters, no annotations), the description is extremely complete. It includes parameter details, return structure, and operational context. The presence of an output schema in the description further enhances completeness. An agent has all the information needed to correctly invoke the tool.

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

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

The input schema has 0% description coverage, but the description compensates thoroughly by explaining each parameter: 'group_stix_id' is described as a STIX UUID with an example, 'domain' lists allowed values, and 'include_description' clarifies its boolean purpose. This adds essential meaning beyond the schema's bare types and titles.

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

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

The description clearly specifies the verb 'Get', the resource 'campaigns', and the scope 'attributed to a specific intrusion set', with a note on STIX ID identification. It distinguishes itself from sibling tools like `get_all_campaigns` and `get_campaigns_by_alias` by focusing on attribution to a specific group.

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

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

The description provides context that the tool is for campaigns attributed to a specific group, implying usage when the agent has a group STIX ID. However, it lacks explicit alternative guidance or when-not-to-use scenarios, though the context is clear enough for an agent to decide.

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

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

With no annotations, the description carries full burden. It details the return format, case-insensitivity of alias, and optional parameters. However, it does not mention error handling or behavior when alias is not found, though the output schema implies a message field.

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

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

The description is well-structured with a header, explanation, and Args/Returns sections. It is appropriately sized for a tool with 3 parameters and an output schema. Could be slightly more concise but no wasted sentences.

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

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

Given the complexity (3 params, output schema, many siblings), the description covers purpose, alias resolution, parameter details, and return structure. Missing explicit error handling or edge cases, but overall complete for a get operation.

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

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

Schema description coverage is 0%, so the description must explain parameters. It does so effectively: alias is described as case-insensitive, domain is 'ATT&CK domain', and include_description is 'Include campaign descriptions in output'. This adds full meaning beyond the schema titles.

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

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

The description clearly states the verb 'Get' and resource 'campaigns by their alias', distinguishing from sibling tools like 'get_campaigns_attributed_to_group' or 'get_campaigns_using_software'. The explanation of alias resolution adds specificity.

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

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

The description provides context on when to use this tool ('resolve aliases') but does not explicitly exclude alternatives or state when not to use it. Sibling tools exist for different filters, so a comparative note would be helpful.

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

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

With no annotations provided, the description carries the full burden. It details the return structure comprehensively and indicates it is a read operation. However, it does not mention potential performance implications, pagination, or any side effects.

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

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

The description is well-structured and concise, starting with a clear statement of purpose, followed by a brief conceptual note, then detailed but essential parameter and return descriptions. Every sentence adds value.

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

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

Given the tool's moderate complexity and that an output schema is provided, the description is thorough. It covers inputs and outputs completely, but lacks explicit notes on how it differs from sibling tools or error handling scenarios.

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

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

Schema coverage is 0%, but the description compensates fully by providing clear descriptions for all three parameters, including format examples for software_stix_id and enumerating domain options.

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

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

The description clearly states the tool's purpose: 'Get all campaigns that use specific software/malware.' It emphasizes 'reverse lookup: Software → Campaigns', which distinguishes it from sibling tools like get_campaigns_attributed_to_group or get_campaigns_using_technique.

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

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

The description implies usage by mentioning it's a reverse lookup, but it does not explicitly state when to use this tool versus alternatives. It lacks guidance on prerequisites or context where other tools might be more appropriate.

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

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

No annotations are provided, so the description must disclose behavior. It details the return structure and parameter effects but does not state that the tool is read-only, has no side effects, or mention any rate limits or authentication needs. The returned output schema is well-described, but the missing safety profile leaves some ambiguity.

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

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

The description is front-loaded with the purpose, then clearly separates Args and Returns. While the return structure is lengthy, it is justified by the presence of an output schema. Every sentence adds value, but minor redundancy exists (e.g., repeating 'null' in multiple places).

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

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

Given no annotations and no schema descriptions, the description is quite complete: it covers all parameters, the full return object, and status fields. It lacks error handling info and prerequisites, but for a read-only reverse lookup tool, this is sufficient.

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

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

Schema description coverage is 0%, so the description must compensate. The 'Args' section explains all three parameters: technique_stix_id (with example format), domain (with valid values), and include_description (as boolean). This adds substantial meaning beyond the bare schema.

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

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

The description clearly states it retrieves all campaigns using a specific technique, and explicitly labels it a reverse lookup (Technique → Campaigns). This distinguishes it from siblings like get_campaigns_attributed_to_group or get_campaigns_using_software.

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

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

The description implies when to use this tool (to find campaigns by technique) but does not explicitly specify when not to use it or compare to alternatives. The phrase 'reverse lookup' provides some guidance, but lacks exclusions or context for selection among many sibling tools.

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

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

Beyond annotations (none provided), the description discloses the two operational modes, fallback logic, and the addition of a debug block. However, it does not mention side effects, authentication requirements, or rate limits. For a read-only tool, this is adequate but incomplete.

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

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

The description is relatively concise and well-structured, using clear sections for primary and fallback modes. It avoids unnecessary verbiage, though the bullet list could be slightly more compact.

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

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

Given no output schema or annotations, the description is insufficient. It does not describe the return format, debug block content, or clarify 'same structure as before'. Parameter descriptions are absent, leaving major gaps for invocation.

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

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

The input schema has 0% description coverage, and the tool description does not explain any of the three parameters ('domain', 'technique_stix_id', 'include_description'). The description discusses data source resolution but not parameter meaning or usage.

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

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

The description clearly states it retrieves data components that detect a specific technique. It specifies the resource ('data components') and verb ('Get'), and distinguishes from reverse tools like get_techniques_detected_by_datacomponent. The primary and fallback modes are outlined.

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

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

The description explains two modes (primary and fallback) with conditions for use. It details fallback logic when relationship traversal yields zero results. However, it does not explicitly mention when to use this tool versus its reverse counterpart, leaving some ambiguity.

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

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

With no annotations, the description sufficiently discloses the tool's behavior: it returns read-only statistics and assumes downloads were attempted at startup. No side effects are mentioned, but none are expected for a read-only tool.

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

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

The description is two sentences, front-loaded with the main purpose, and every word adds value. No wasted content.

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

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

Given the tool has no parameters and an output schema exists, the description adequately covers the tool's functionality and assumptions. It could mention error conditions, but the essential context is present.

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

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

The tool has no parameters, and the empty schema is fully covered. The description adds no additional parameter information, but none is needed.

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

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

The description clearly states the tool returns statistics about downloaded MITRE ATT&CK STIX data, specifying what is included (domains, file paths, sizes, release version). It is distinct from sibling tools like 'get_stats' and other entity-specific tools.

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

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

The description implies usage after server startup to check downloaded data. It provides clear context for when to use the tool, though it does not explicitly exclude alternatives or compare with siblings.

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

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

Despite no annotations, the description fully discloses behavior: returns first matching group, case-insensitive, partial matches, and details the return schema including 'found' and 'message' fields.

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

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

The description is well-structured with examples and args, but slightly verbose with repeated mention of 'case-insensitive'. Still efficient and front-loaded with purpose.

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

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

Given the output schema is fully documented in the description and the tool is simple, the description covers all aspects: purpose, parameters, behavior, return format, and example usage.

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

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

Schema coverage is 0%, but the description adds meaning for all three parameters: group_name (case-insensitive search), domain (ATT&CK domain with default), include_description (controls output). This fully compensates for missing schema descriptions.

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

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

The description clearly states the verb 'retrieve' and resource 'intrusion set (APT group)' by name or alias, distinguishing it from siblings like get_all_groups (returns all groups) and search_groups (broader search).

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

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

The description explains when to use (search by name/alias with case-insensitive partial matching) and includes examples, but does not explicitly say when not to use or compare with alternatives like get_groups_by_alias.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return structure in detail and explains arguments, but it does not mention any behavioral traits such as idempotency, error handling, permissions, or rate limits. For a read-only get operation, this is adequate but not exceptional.

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

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

The description is well-structured: a clear one-sentence purpose, a brief explanation, then separate 'Args' and 'Returns' sections. While the return block is long, it is necessary due to the absence of a separate output schema. No superfluous text.

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

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

Given the tool's moderate complexity (3 parameters, no enums, no formal output schema), the description covers purpose, all parameters, and the full return structure. It lacks notes on error conditions or edge cases (e.g., invalid STIX ID), but for a straightforward lookup tool, it is largely complete.

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

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

The input schema has 0% description coverage, yet the description provides an 'Args' section that explains each parameter (campaign_stix_id, domain with allowed values, include_description) and their defaults. This adds significant meaning beyond the raw schema, compensating for the lack of schema descriptions. Baseline for 3 parameters is 3, but the description elevates it to 4.

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

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

The description clearly states the tool retrieves APT groups attributed to a specific campaign, explicitly labels it as a 'reverse lookup: Campaign → Groups', and distinguishes it from sibling tools like get_campaigns_attributed_to_group (the opposite direction). The verb 'Get' and resource 'APT groups' are specific.

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

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

The description implies when to use it (when you have a campaign STIX ID and want groups) via the 'reverse lookup' phrasing, but it does not explicitly state when not to use it or name alternative tools for other scenarios (e.g., get_groups_using_software for software-based lookups).

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

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

No annotations are provided, so the description bears full burden. It discloses the case-insensitive exact match behavior, return structure, and alias concept. It does not mention side effects or limitations, but as a read-only query, this is sufficient.

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

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

The description is well-structured with examples and Args/Returns sections, but it is slightly verbose. The purpose is front-loaded, and every part adds value.

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

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

Given the tool complexity (alias matching, multiple groups, optional parameters), the description fully documents input, behavior, and return structure. The output schema is described in text, providing complete context.

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

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

Schema description coverage is 0%, but the description provides detailed parameter explanations, including alias examples, domain enumeration, and include_description default. It adds significant value beyond the schema.

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

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

The description clearly states it retrieves APT groups by alias, provides examples, and distinguishes from siblings like get_group_by_name and search_groups by focusing on alias matching.

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

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

The description explains what the tool does but does not explicitly state when to use it versus alternatives or when not to use it. It implies usage context through examples but lacks direct guidance.

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

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

No annotations are provided, so the description carries full responsibility. It details the return format and relationships covered ('uses'), but does not mention behavioral traits such as read-only nature, permission requirements, or side effects. The detailed output schema partly mitigates this, but explicit safety or behavioral notes are missing.

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

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

The description is well-structured with clear sections (Args, Returns). While the inclusion of the entire output schema is helpful, it makes the description somewhat lengthy. The first paragraph is concise and front-loaded with the core purpose.

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

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

Given that an output schema is provided within the description, the tool is fairly complete: it covers input parameters, return structure, and the relationship direction. However, it omits discussion of prerequisites, error handling, or edge cases (e.g., no groups found), which would enhance completeness.

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

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

The input schema has only titles and defaults, with no parameter descriptions. The description's 'Args' section adds crucial meaning: it explains that software_stix_id expects a UUID with a specific prefix, domain lists valid options, and include_description clarifies its boolean purpose. This fully compensates for the schema's lack of descriptions.

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

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

The description clearly states 'Get all APT groups (intrusion sets) that use a specific software/malware' and identifies it as a 'reverse lookup: Software → Groups'. The verb is specific, the resource is well-defined, and the direction distinguishes it from siblings like get_groups_using_technique or get_software_used_by_group.

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

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

The description explains the reverse lookup direction, which implicitly guides when to use this tool (when you have a software and want groups). However, it does not explicitly state when not to use it or compare to alternatives like get_software_used_by_group, which serves the opposite direction.

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

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

With no annotations, the description carries the full burden. It details the relationship traversal ('follows uses relationships from a technique STIX ID to intrusion sets') and provides an exhaustive return schema. It does not disclose potential side effects or permissions, but the operation is inherently read-only.

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

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

The description is fairly long due to the included return schema, but it is well-structured: brief intro, Args list, and Returns section. It is front-loaded with purpose. A minor reduction could be made, but it remains efficient.

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

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

Despite the output schema being provided, the description still covers the return structure. All three input parameters are described. For a reverse lookup tool with moderate complexity, the description is fully adequate.

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

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

Schema description coverage is 0%, so the description must compensate. The Args section explains each parameter: technique_stix_id with format example, domain with valid values, and include_description with semantics. This adds substantial meaning beyond the bare schema.

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

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

The description starts with a clear verb-resource phrase: 'Get all APT groups (intrusion sets) that use a specific technique.' It further distinguishes itself as a reverse lookup ('Technique → Groups'), differentiating it from sibling tools like get_techniques_used_by_group.

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

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

The description explicitly states this is a reverse lookup and follows 'uses' relationships, implying when to use it. Sibling tools include get_techniques_used_by_group (the forward direction), providing implicit differentiation. However, it lacks explicit when-not-to-use or alternative tool instructions.

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

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

No annotations exist, so the description carries the full burden. It discloses the lookup process, partial matching, and output structure. However, it does not explicitly state that the operation is read-only or has no side effects, which is minor given the clear intent.

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

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

The description is well-structured with clear sections for purpose, steps, args, and output. It is somewhat lengthy but each part serves a purpose. Minor redundancy in args list versus schema.

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

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

Given the presence of an output schema, the description adequately covers return values. It lacks details on error handling (e.g., group not found) but the output includes a 'found' boolean. Overall, it is sufficiently complete for a retrieval tool.

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

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

With 0% schema description coverage, the description fully explains all three parameters, their defaults, and the group_name lookup semantics. This adds essential meaning beyond the schema's property titles.

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

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

Description clearly states the tool retrieves all techniques used by a specific APT group, with matching details (case-insensitive, partial). This distinguishes it from siblings like get_software_used_by_group or get_groups_using_technique.

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

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

The description implies usage for group techniques but does not explicitly guide when to choose this over alternatives. No exclusions or comparisons to sibling tools are provided, leaving the agent to infer context.

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

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

No annotations are provided, so the description carries full burden. It implies a read-only retrieval by describing it as returning a template, but does not explicitly state side effects (none) or permissions required. The transparency is adequate but could be more explicit about non-destructive behavior.

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

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

The description is concise and well-structured, with a clear purpose statement followed by an Args/Returns section. Every sentence adds value, and the key information is front-loaded.

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

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

Given the tool's simplicity (one optional parameter) and the presence of an output schema in the description, the description covers the parameter, return format, and use case. It is complete enough for a metadata retrieval tool, though it omits error conditions.

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

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

The input schema has 0% description coverage, but the description's Args section explains the domain parameter with valid values ('enterprise', 'mobile', 'ics') and default. This adds meaningful guidance beyond the bare schema, though it lacks formal enum constraints.

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

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

The description clearly states it returns a standard ATT&CK Navigator layer metadata template and explains its contents (version info, gradient settings, etc.). It distinguishes from siblings like generate_layer by implying this is a base template for building custom layers, though not explicitly naming alternatives.

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

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

The description indicates when to use (building custom layers programmatically) but does not explicitly state when not to use or mention alternative tools like generate_layer. It provides usage context but lacks exclusions.

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

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

No annotations are provided, so the description must disclose behavior. It explains that the helper returns a list of RelationshipEntry[Mitigation] requiring unwrapping, and provides the full response schema. This is sufficient for a read-only query with no side effects.

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

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

The description is 7 lines, includes a somewhat technical reference to 'list[RelationshipEntry[Mitigation]]', and could be more concise. However, it is front-loaded with the primary purpose and uses clear language.

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

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

Given the output schema is provided, the description's inclusion of the return structure adds value but does not compensate for missing parameter descriptions. The tool is simple (read-only, few parameters), so completeness is adequate but not exemplary.

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

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

Schema coverage of parameters is 0%—the description adds no information about 'technique_stix_id', 'domain', or 'include_description' beyond their names and defaults. The description does not clarify expected formats, constraints, or usage patterns for these parameters.

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

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

Description explicitly states 'Get all mitigations that address a specific technique', providing a clear verb (Get), resource (mitigations), and scope (for a specific technique). This distinguishes it from siblings like 'get_all_mitigations' (all mitigations) and 'get_techniques_mitigated_by_mitigation' (reverse mapping).

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

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

The description implies usage for a specific technique but provides no when-to-use or when-not-to-use guidance, nor does it reference alternative tools from the sibling list. The context is implied but not explicitly stated.

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

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

No annotations are provided, so the description carries full burden. It details input/output structure and examples, but does not disclose side effects, required permissions, safety profile, or limitations. The tool appears to be a simple lookup, but behavioral traits like read-only nature are not explicitly stated.

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

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

The description is well-structured with separate sections for purpose, input examples, parameter listing, and return format. It is appropriately sized, front-loading the main action, and every sentence adds value. No redundant or vague statements.

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

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

Given the tool's simplicity and the presence of an output schema, the description is complete. It covers the conversion logic, parameter specifics, return format with fields, and status codes via the message field. No missing critical details.

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

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

Schema coverage is 0%, so the description must compensate. It defines both parameters (stix_id, domain) with concrete examples and expected values. The domain parameter's default and possible values are implied, but not exhaustive. This adds meaning beyond the bare schema types.

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

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

The description clearly states the tool's purpose: 'Resolve the human-readable object name for a given STIX ID.' It provides concrete examples of input and output, making the conversion specific and immediately understandable. This distinguishes it from sibling tools that retrieve full objects or lists.

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

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

The description explains when to use the tool (when you have a STIX ID and need the readable name) and gives context on the types of STIX IDs and domains. It does not explicitly state when not to use it or mention alternatives, but the examples and parameter listing provide implicit guidance.

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

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

No annotations provided, so description carries the burden. It clearly indicates this is a read operation ('Retrieve') and provides the full return schema, including a 'found' flag for missing objects. It lists supported object types and explains each parameter's role. However, it does not disclose potential rate limits or authentication needs, but these are likely minimal.

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

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

The description is well-structured with a purpose statement followed by notes, args, and returns. It is concise at about 12 lines, with no redundant sentences. The front-loading is effective. Minor improvement: could combine the supported types list into one line for even tighter prose.

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

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

The description is complete for a lookup tool with 4 parameters and an output schema. It covers all parameter details, return format with fields, and lists supported object types. The output schema is clearly described, so the agent knows what to expect. No gaps for typical usage.

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

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

Schema description coverage is 0%, but the description compensates fully with an 'Args:' section that explains each parameter with examples (e.g., 'T1055', 'G0016'), allowed domain values ('enterprise', 'mobile', 'ics'), and the boolean include_description. This adds meaning beyond the schema's property definitions.

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

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

The description clearly states the tool's purpose: 'Retrieve any MITRE ATT&CK object by its external ATT&CK ID and STIX type.' It lists supported object types, making the scope explicit. This distinguishes it from siblings like get_object_by_stix_id (different lookup key) or get_objects_by_type (returns list).

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

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

No explicit guidance on when to use this tool versus alternatives. With many sibling tools (e.g., get_object_by_stix_id, get_objects_by_name), the description should mention typical use cases, but it does not. The implied usage is when you have the external ATT&CK ID and STIX type, but no exclusions or comparisons.

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

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

No annotations provided, so the description carries full burden. It discloses the return format with fields (found, object, formatted, message) and implies a read-only operation. More details on error handling or permissions could be added, but the core behavior is clear.

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

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

The description is well-structured with an intro, explanation, Args, and Returns. It is concise, front-loads the purpose, and every sentence adds value. No redundancy.

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

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

Given the output schema exists (context: true), the description still covers return fields. Parameters are fully documented. The description is complete for resolving objects by STIX ID, covering purpose, usage, parameters, and output. No gaps.

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

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

Schema coverage is 0%, so the description must compensate. The 'Args' section explains each parameter: stix_id format, domain options ('enterprise', 'mobile', 'ics'), and include_description purpose. This adds significant meaning beyond the schema.

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

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

The description clearly states 'Retrieve any MITRE ATT&CK object by its STIX ID (UUID).' This is a specific verb (retrieve) and resource (MITRE ATT&CK object) and distinguishes from siblings like 'get_object_by_attack_id' which uses a different identifier.

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

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

The description says 'This tool is useful when you already have a STIX ID from another query or relationship and want to resolve it to the full object.' This provides clear context for when to use it. It does not explicitly exclude cases or name alternatives, but the guidance is sufficient.

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

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

With no annotations provided, the description carries full burden for behavioral transparency. It discloses that the search is case-insensitive partial match over descriptions, and details the return format (count, objects, formatted, message). It implies read-only behavior, but does not explicitly state safety or side-effect absence, which would strengthen transparency.

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

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

The description is well-structured with a clear purpose statement, bullet points for use cases, and a detailed return format example. It is somewhat lengthy but each section adds value. Front-loading the core action aids quick understanding.

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

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

Given the 4 parameters, no annotations, and presence of an output schema, the description covers search behavior, parameter details, use cases, and return format. It does not discuss error handling or performance, but it provides sufficient context for effective use.

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

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

Schema description coverage is 0%, so the description must fully explain each parameter. It does so thoroughly: content (case-insensitive partial match), object_type (with example STIX types), domain (with example values), and include_description (boolean). It adds meaning not present in the schema, making parameter usage clear.

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

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

The description clearly states the tool searches MITRE ATT&CK objects by matching text inside their description field. It provides specific use case examples (finding techniques by technology, groups by region, etc.), which differentiates it from sibling tools like get_objects_by_name (name search) or search_techniques (which may search other fields).

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

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

The description lists explicit use cases (finding techniques by technology, groups by region, etc.) that clarify when to use this tool. However, it does not explicitly mention when not to use it or compare it to alternative tools like search_techniques or get_objects_by_name, so there is minor room for improvement.

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

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

With no annotations provided, the description carries the full burden. It thoroughly explains the tool's behavior: exact match, case-sensitive, returns structured results with count, objects, formatted text, and a message. No hidden side effects are omitted.

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

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

The description is well-structured with a clear overview, examples, parameter details, and return format. Every sentence contributes value, and the most important information is front-loaded.

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

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

Even though an output schema exists, the description still fully documents the return structure. It covers all necessary aspects for the tool's purpose, leaving no gaps.

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

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

The input schema has 0% description coverage, so the description fully compensates. It explains each parameter: name (exact name, case-sensitive), stix_type (with examples of valid types), domain (with options), and include_description (boolean, default false). This adds critical meaning beyond the schema.

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

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

The description clearly states the tool retrieves MITRE ATT&CK objects by exact name match, case-sensitive, and distinguishes itself from generic search methods by emphasizing strictness. Examples of usage with specific object types further clarify the purpose.

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

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

The description indicates the tool is for exact name matching and is more strict than generic search methods, implying when to use it. However, it does not explicitly state alternatives or when not to use this tool, leaving some ambiguity.

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

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

No annotations are provided, so the description must disclose behavioral traits. While 'get' implies read-only, the description does not explicitly state it is non-destructive or discuss permissions, rate limits, or side effects.

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

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

Well-structured with clear sections (purpose, common types, Args, Returns). The list of common STIX types is helpful but slightly lengthy. Overall concise and front-loaded.

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

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

Given 4 parameters and an output schema described inline, the description covers all essential aspects: parameters, return format, and behavior (removing revoked/deprecated). It is complete for an agent to invoke correctly.

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

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

With 0% schema coverage, the description adds extensive meaning: it describes each parameter (stix_type, domain, remove_revoked_deprecated, include_description) including defaults and provides common STIX type examples. The Returns section also explains output structure.

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

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

The description clearly states the tool retrieves all objects of a specific STIX type, listing common types and explicitly contrasting with more specific sibling tools like get_all_techniques().

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

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

The description notes it complements more specific tools, providing implicit guidance. However, it lacks explicit when-not-to-use or direct comparisons with alternatives.

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

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

No annotations provided, so description must bear full transparency burden. It documents the return structure in detail but does not disclose potential side effects, limitations (e.g., pagination, performance), or error conditions. Adequate but not thorough.

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

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

Concise yet detailed. Returns inline specifies output structure, saving space. No redundant sentences. Well-organized.

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

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

Output schema covers return values well. Parameter semantics are partially covered. Overall, adequate for basic use but incomplete for advanced usage scenarios (e.g., no guidance on `domain` values).

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

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

Schema description coverage is 0%, so description must compensate. It explains `timestamp` format but does not clarify `domain` (default 'enterprise') or `include_description` (default true). Missing parameter details reduce effectiveness.

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

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

Clearly states the verb 'Get', resource 'ATT&CK objects', and condition 'created after a specific timestamp'. Distinguishes from sibling tools like `get_objects_modified_after` by focusing on creation time.

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

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

Provides explicit usage context: 'Useful for detecting new additions to the framework.' Includes format requirement for timestamp. Does not explicitly state when not to use or compare to alternatives, but gives enough guidance for typical use.

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

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

Provides timestamp format requirement and full output schema, but no annotations exist; lacks disclosure on side effects or authentication, which are minimal for a read operation.

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

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

Concise with front-loaded purpose, usage hint, format note, and structured output schema. Every sentence adds value.

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

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

Output schema covers return values, but missing parameter explanations for domain and include_description; additional context on scope or performance would help.

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

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

Only describes timestamp format; domain and include_description parameters are unexplained despite 0% schema coverage, leaving gaps for the agent.

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

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

Description clearly states the tool gets all ATT&CK objects modified after a timestamp, using a specific verb and resource, and distinguishes from siblings like get_objects_created_after.

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

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

Describes use for tracking updates and changes, but does not explicitly specify when to use this tool versus alternatives or provide when-not conditions.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool returns a structured object (subtechnique_stix_id, subtechnique_attack_id, parent object, formatted, message) and may return null for missing parents. This gives a good understanding of the tool's output, though it omits error handling details (e.g., invalid STIX ID).

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

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

The description is well-structured: a one-line purpose, an 'Args' section, and a 'Returns' section. It is front-loaded with the core action. However, the Returns section includes the full JSON structure which is somewhat lengthy; it could be slightly more concise by summarizing the return format without the full JSON example.

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

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

Given the schema richness (3 parameters, 1 required) and presence of an output schema (described), the description covers all aspects: parameters, return structure, and a fallback (null). However, it does not provide examples, error cases, or mention any prerequisites (e.g., the subtechnique must exist). 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.

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

Schema parameter description coverage is 0%, so the description fully compensates by explaining each parameter: 'technique_stix_id: STIX UUID of the subtechnique', 'domain: ATT&CK domain', 'include_description: Whether to include the parent's description', including defaults. This adds complete meaning beyond the raw schema.

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

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

The description clearly states the tool's function: 'Get the parent technique of a subtechnique.' This is a specific verb+resource pair that distinguishes it from sibling tools like 'get_subtechniques_of_technique' (reverse operation) and 'get_all_parent_techniques' (different scope).

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

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

The description does not explicitly mention when to use this tool versus alternatives. While the purpose is clear, there is no guidance on when not to use it or how it compares to sibling tools like 'get_all_parent_techniques' or 'get_subtechniques_of_technique'. The context signals only provide the sibling list without differentiation.

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

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

With no annotations, the description discloses it's a read operation via 'Get all procedure examples'. It details the return format and parameters, though it could explicitly state no side effects or idempotency.

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

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

The description is concise yet comprehensive, with clear sections for args and returns. Every sentence serves a purpose, and the bullet format aids readability.

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

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

Given the presence of an output schema, the description covers all necessary aspects: purpose, parameters with defaults, and return structure. It is complete for an AI agent to select and invoke correctly.

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

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

Schema coverage is 0%, but the description provides semantics for each parameter: case-insensitivity for tactic, default for domain, boolean for include_description. This adds value beyond the schema's type info.

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

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

The description clearly states it retrieves procedure examples for techniques within a specific tactic, using the verb 'Get' and identifying the resource. It distinguishes itself from siblings like get_procedure_examples_by_technique by focusing on a tactic vs. a single technique.

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

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

The description explains when to use this tool (for examples grouped by tactic) and implies it's for ATT&CK data. It does not explicitly mention when not to use or name alternatives, but the sibling list provides context.

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

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

No annotations are provided. The description does not disclose any behavioral traits such as side effects, authentication requirements, rate limits, or idempotency. It only states that the tool returns procedure examples, which is minimal behavioral context.

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

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

The description is concise with only a few lines. It includes a docstring summarizing parameters and return value. However, it could be more structured (e.g., separating usage from return format). No fluff.

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

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

Given the tool has 3 parameters and an output schema (provided in the description), the description is fairly complete. It explains the purpose, parameters, and return format. It could mention valid domain values, but overall adequate.

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

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

Schema description coverage is 0%, so the description must add meaning. It lists the parameters in a docstring but does not explain what values are valid for domain (e.g., 'enterprise', 'mobile') or what include_description truly does. The description adds little beyond the parameter names and types.

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

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

The description clearly states the tool retrieves procedure examples for a specific technique, with a verb 'Get' and resource 'procedure examples by technique'. It distinguishes from sibling tools like get_procedure_examples_by_tactic by specifying 'by technique' in the name and description.

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

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

The description implies the tool is used for looking up procedure examples for a given technique, but does not explicitly state when to use it versus alternatives (e.g., get_procedure_examples_by_tactic) or provide any exclusions. No guidance is given on prerequisites or context.

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

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

No annotations are provided, so the description carries full burden. It describes the output structure and explains the nature of revoked techniques (read-only). However, it lacks details on authorization requirements, side effects, or performance considerations.

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

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

The description is short and front-loaded with the core purpose. The code block for return format is useful and well-structured. No extraneous sentences.

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

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

Given two undocumented parameters and many sibling tools, the description is incomplete. It lacks parameter documentation and fails to provide enough context for an agent to use the tool correctly without prior knowledge.

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

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

With 0% schema description coverage, the description adds no meaning to parameters. It mentions 'domain' in the first sentence but does not explain that it defaults to 'enterprise' or what values are accepted. The include_description parameter is entirely undocumented.

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

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

The description clearly states that the tool retrieves revoked techniques for a domain, and explains what revoked techniques are. It distinguishes itself from other tools by specifying a subset (revoked) but does not explicitly differentiate from siblings that may also return lists.

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

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

The description offers no guidance on when to use this tool versus alternatives like get_all_techniques or get_technique_by_id. It does not provide context for appropriate usage or exclusions.

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

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

With no annotations, the description fully carries the transparency burden. It discloses that only non-revoked, non-deprecated software objects are returned and includes both malware and tools. It also describes the output structure in detail. While it does not explicitly declare the tool as read-only, the behavior is clearly for retrieval, and no side effects are implied.

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

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

The description is well-structured with Docstring sections (Args, Returns) but is relatively lengthy. It includes the full return schema, which is redundant since an output schema exists. While clear, it could be more concise by relying on the structured output schema rather than repeating it in text.

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

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

Given the simplicity of the tool (2 optional parameters, output schema present), the description is complete. It explains the filtering logic (domain, revoked/deprecated exclusion), parameter effects, and the return format. No critical gaps remain for an agent to use the tool correctly.

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

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

The input schema has 0% coverage (no parameter descriptions), so the description must compensate fully. It does so by explaining the 'domain' parameter with example values ('enterprise', 'mobile', 'ics') and the 'include_description' boolean effect. This adds essential meaning beyond what the raw schema provides.

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

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

The description clearly states the tool retrieves all software (malware and tools) for a given ATT&CK domain, specifying it returns non-revoked, non-deprecated objects. This distinguishes it from sibling tools like 'get_all_software' (which likely lacks domain filtering) and 'search_software' (which enables flexible search by name/alias).

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

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

The description explicitly conditions usage on the 'domain' parameter, indicating the tool is appropriate when software from a specific ATT&CK domain is needed. However, it does not directly state when to avoid this tool (e.g., for cross-domain queries) or explicitly name alternative tools like 'get_all_software'.

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

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

With no annotations provided, the description carries the full burden. It describes the search operation and return structure, but does not disclose side effects, permissions, or failure modes. It is adequate but not exhaustive.

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

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

The description is concise with a clear summary followed by structured Args and Returns sections. It is front-loaded and efficient, though the documentation of returns partially overlaps with the output schema.

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

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

Given the tool has 3 parameters and an output schema, the description is fairly complete: it explains purpose, parameters, return structure, and the context of aliases. It does not cover edge cases but is sufficient for an AI agent.

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

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

Schema description coverage is 0%, but the description provides an 'Args:' section that explains each parameter (alias, domain, include_description) beyond just the parameter names. This adds meaningful context.

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

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

The description clearly states 'Find software/malware by alias' and explains that it searches the software catalog for alias matches. This is specific verb+resource and distinguishes from siblings like 'get_all_software' or 'search_software'.

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

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

The description implies usage when searching by an alias, noting that many tools have multiple names. However, it does not explicitly state when to use this tool versus alternatives like 'get_groups_by_alias' or 'get_campaigns_by_alias', nor does it provide exclusions.

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

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

With no annotations, the description carries the full burden. It explains the parameters and provides a detailed return structure, including the formatted human-readable list and status message. However, it does not mention potential side effects or permissions requirements.

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

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

The description is well-structured with Args and Returns sections, but the inline output schema example is lengthy. The core purpose is front-loaded, but some detail could be streamlined without losing clarity.

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

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

Despite the lack of annotations, the description provides complete guidance: all parameters are explained, and the return structure is fully specified. This enables correct invocation and interpretation of results.

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

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

Schema coverage is 0%, so the description must add meaning. It explains each parameter: campaign_stix_id (with example format), domain (with allowed values), and include_description (with default). This fully documents parameter semantics beyond the bare schema.

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

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

The description begins with 'Get all software/malware used in a specific campaign,' clearly stating the verb and resource. This distinguishes it from siblings like get_software_used_by_group and get_campaigns_using_software, which target different entities.

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

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

No guidance is provided on when to use this tool versus alternatives. The description lacks explicit context on prerequisites (e.g., needing a campaign STIX ID) or situations where other tools like get_campaigns_using_software would be more appropriate.

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

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

No annotations provided, so description carries full burden. It details the underlying mechanism (following 'uses' relationships) and provides a complete return format including group, count, software with nested relationships. Missing potential constraints like pagination or performance, but still excellent transparency.

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

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

Well-structured: purpose first, then method, parameters, and full return spec. The output schema is thorough but a bit verbose. However, the detail is appropriate for a complex data retrieval tool.

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

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

Given the complex return format and 0% parameter descriptions, the tool definition provides everything an agent needs: purpose, usage context, all parameter details, and a complete output schema. No gaps.

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

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

Schema description coverage is 0%, so description must compensate. It clearly explains each parameter: group_stix_id with example UUID, domain with allowed values, include_description with boolean purpose. This adds significant meaning beyond the bare schema.

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

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

The description clearly states 'Get all software (malware and tools) used by a specific APT group, identified by its STIX ID.' This is a specific verb-resource combination that effectively distinguishes it from siblings like get_all_software, get_groups_using_software, and get_software_used_by_campaign.

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

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

The description explains it follows 'uses' relationships from intrusion set to software and lists parameters, but does not explicitly state when to use this tool vs alternatives like get_groups_using_software or get_software_used_by_campaign. Given many sibling tools, some guidance on selection would be beneficial.

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

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

With no annotations, description provides full behavioral disclosure of output structure including relationships array. It does not mention safety or performance, but as a read query, the detailed return format is adequate.

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

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

Well-structured with clear Args and Returns sections. First sentence is front-loaded. Slightly long due to detailed output example, but every sentence adds value.

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

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

Complete for the tool's complexity: covers purpose, all parameters, and full return structure. Even provides an example output, which compensates for no output schema in metadata.

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