Server Quality Checklist

Tool Scores

• audit_rds_postureA
  4.4/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint and non-destructive behavior, and the description adds substantial behavior beyond that: it scans every RDS instance, assigns HIGH/MEDIUM/LOW severities, and returns the {check, ok, findings[], scanned} envelope with per-finding fields. This gives the agent a clear model of what the tool will do and return.

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

  Conciseness5/5

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

  The description is organized into three dense, purposeful parts: a one-line purpose statement, a scope-and-severity explanation, and a return envelope description. Every sentence adds value and the most identifying information is front-loaded.

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

  Completeness4/5

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

  Because there is no output schema, the description correctly documents the return shape including the envelope and finding fields. It is nearly complete for a read-only RDS audit, but the region parameter's default and format are left under-specified.

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

  Parameters3/5

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

  The schema has one optional region parameter with 0% description coverage. The prose mentions 'in the region,' implying the parameter scopes the scan, but it does not explain the null default, accepted region format, or behavior when omitted. The description partially compensates but leaves the parameter semantics implicit.

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

  Purpose5/5

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

  The description opens with 'Audit RDS instance posture' and immediately lists the three concrete dimensions checked: public accessibility, storage encryption, and deletion protection. This specific verb+resource+scope clearly distinguishes it from the sibling audit tools, which target accounts, lambdas, EBS volumes, security groups, and other resources.

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

  Usage Guidelines4/5

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

  The description makes the usage context clear by stating that it scans every RDS DB instance in the region and reports posture findings. It does not explicitly name alternatives or state when not to use it, such as pointing to audit_full_posture for a broader audit, so it misses the full exclusion guidance.

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

• account_security_summaryA
  4.5/5.0
  Behavior5/5

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

  Even though annotations already declare the tool read-only and non-destructive, the description goes further by naming the underlying AWS API calls (sts.GetCallerIdentity, iam.GetAccountSummary, s3control.GetPublicAccessBlock), specifying exact finding thresholds, and detailing the return envelope. This gives an agent a precise model of what the tool will and won't do.

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

  Conciseness5/5

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

  The description is well organized into 'Collects', 'Findings', and 'Returns' sections, and every line carries useful information. The opening sentence is a compact summary, and the nested detail is front-loaded and easy to scan without being padded.

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

  Completeness5/5

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

  Given the tool has no parameters and no output schema, the description fully compensates by explaining the return envelope structure, finding severities, and what each collected value contributes. It also covers edge cases like a missing S3 public access block. An agent has all the information needed to invoke and interpret this tool.

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

  Parameters4/5

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

  The tool has no parameters and the schema description coverage is 100%, so the schema already fully documents the input surface. The description adds no parameter semantics because none are needed; the baseline of 4 for zero-parameter tools applies.

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

  Purpose5/5

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

  The description clearly states a specific action ('Cheap posture snapshot') on a specific resource ('audited AWS account'), then enumerates exactly what data is collected and which findings are generated. This makes the tool's purpose concrete and distinguishes it from the more specialized audit_* sibling tools.

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

  Usage Guidelines3/5

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

  The phrase 'cheap posture snapshot' implies a lightweight, account-level overview rather than a deep audit, which provides some usage context. However, the description never explicitly states when to use this tool instead of alternatives like audit_full_posture or audit_root_account_posture, nor does it list exclusions. Usage guidance is implied, not spelled out.

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

• audit_lambda_resource_policiesA
  4.6/5.0
  Behavior5/5

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

  Beyond the readOnlyHint and non-destructive annotations, the description details scanning scope, region defaulting to AWS_REGION or us-east-1, severity classification logic for wildcard and service principals, and the exact conditions under which findings are produced. This is far more than the annotations alone provide.

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

  Conciseness5/5

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

  The description is thorough yet economical. It front-loads the purpose, then provides scanning behavior, severity rules, and output format. No sentence is wasted, and the structure flows logically from purpose to invocation details to return value.

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

  Completeness5/5

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

  With no output schema, the description fully explains the return shape: a dict with check, ok, findings, and scanned keys, including details about finding normalization. The single optional parameter is also clarified. The tool is complex, but nothing necessary for correct invocation and interpretation is missing.

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

  Parameters5/5

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

  The schema only defines an optional region parameter with zero description coverage. The tool description compensates by explaining that the region argument defaults to AWS_REGION or us-east-1 when omitted, giving the agent the exact behavior needed to invoke it correctly.

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

  Purpose5/5

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

  The description begins with a specific verb and resource: 'Audit Lambda function resource policies for overly broad invoke access.' It clearly distinguishes this tool from its audit siblings by targeting Lambda resource policies and defining the exact scope of what is inspected.

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

  Usage Guidelines3/5

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

  The description makes the audit context clear and explains the scanning behavior, but it does not explicitly state when to prefer this tool over alternatives such as audit_full_posture or audit_world_open_security_groups. Usage is implied rather than directly contrasted with siblings.

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

• audit_full_postureA
  4.7/5.0
  Behavior5/5

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

  Annotations already indicate read-only and non-destructive behavior. The description adds substantial behavioral detail: failing checks are captured in errors without aborting, the exact response envelope is specified, and the scoring/weighting model is fully explained. This exceeds what annotations convey.

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

  Conciseness5/5

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

  The description is well-structured: the core behavior is front-loaded, followed by the run semantics, return envelope, and scoring rules. Every sentence adds necessary information for correct invocation and interpretation, with no filler.

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

  Completeness5/5

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

  For a zero-parameter tool with no output schema, the description fully covers invocation behavior, error handling, return structure, scoring weights, and grade thresholds. An agent has everything needed to call the tool and interpret its result.

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

  Parameters4/5

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

  The tool has zero parameters, and the schema covers 100% of them by having none. Per baseline, no parameter documentation is needed; the description correctly focuses on behavior and output rather than adding meaningless parameter detail.

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

  Purpose5/5

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

  States a specific verb ('Run every registered audit check') and a concrete deliverable (aggregated account posture report). It clearly distinguishes itself from the sibling tools by describing the aggregation of all audit/account functions rather than a single check.

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

  Usage Guidelines4/5

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

  The description implies when to use this tool (when a full account-wide posture report is needed, as opposed to a specific audit_* sibling) and details what coverage includes. It lacks explicit 'use this instead of X' phrasing but provides clear contextual guidance.

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

• audit_public_bucketsA
  4.7/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description goes far beyond them by detailing exactly what is checked, how findings are classified, what the returned structure is, severity semantics, and how errors are handled. This is unusually transparent.

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

  Conciseness5/5

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

  The description is appropriately structured: a one-sentence summary, a bulleted list of checks and severities, and a concise explanation of the return value and error behavior. Every sentence carries useful information for calling the tool correctly.

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

  Completeness5/5

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

  For a zero-parameter, read-only tool with no output schema, the description completely covers invocation semantics, return shape, finding schema, severity interpretation, and error handling. No important behavioral detail is missing.

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

  Parameters4/5

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

  The tool has zero parameters, so the baseline is 4. The description adds no parameter meaning because none exists, but it clearly identifies the account-wide scope of the operation, which is the only relevant input context.

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

  Purpose5/5

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

  The description states a precise verb and resource: 'Audit every S3 bucket in the account for public exposure.' It clearly differentiates the tool from sibling audit tools by naming the specific AWS service, the account-wide scope, and the security concern it addresses.

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

  Usage Guidelines4/5

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

  The description makes the tool's context clear: it is a focused S3 public-exposure audit covering Public Access Block, bucket policies, and ACLs. It does not explicitly list alternatives or when not to use it, but the scope is specific enough that an agent can select it appropriately among the sibling audit tools.

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

• audit_root_account_postureA
  4.7/5.0
  Behavior5/5

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

  Beyond the readOnlyHint and destructiveHint annotations, the description discloses that it reads the IAM account summary, defines finding severities (HIGH for missing MFA, CRITICAL for root access keys), and details the exact return shape {check, ok, findings[], scanned} including scanned=1 and raw summary values in findings. This is rich behavioral context.

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

  Conciseness5/5

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

  Three tight sentences lead with the tool's core purpose, then explain the data source and findings, then give the return contract. Every sentence adds value and there is no redundant or filler information.

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

  Completeness5/5

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

  For a zero-parameter read-only audit tool with no output schema, the description is fully complete: it names the checks, the severity levels, the response structure, and what each finding's detail contains. An agent has everything needed to invoke the tool and interpret the result.

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

  Parameters4/5

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

  The tool has zero parameters and the schema already covers 100% of them, so the baseline is 4. The description confirms there is nothing to configure and instead focuses on what the tool returns, which is appropriate for a no-input audit tool.

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

  Purpose5/5

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

  The description states a specific action ('Audit the root account') and a specific resource ('root account') with explicit checks: missing MFA and active root access keys. It clearly distinguishes this from sibling audit tools by scoping itself to the root identity.

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

  Usage Guidelines4/5

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

  The description provides clear context that this tool is for auditing the root account only, which implies when to choose it over sibling tools like audit_users_without_mfa. It does not explicitly name alternatives or exclusion criteria, but the root-account scope is unambiguous.

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

• audit_stale_access_keysA
  4.7/5.0
  Behavior5/5

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

  The description goes well beyond the readOnly/destructive annotations by disclosing that it scans every IAM user, flags only Active keys over the threshold, returns a specific shape with findings and scanned, and computes severity based on MFA presence. This gives the agent a clear model of behavior and 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.

  Conciseness5/5

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

  The description is compact and front-loaded: the first sentence states the core purpose, the second describes behavior and return value, and the third covers severity. Each sentence adds necessary information without redundancy or padding.

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

  Completeness5/5

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

  For a single-parameter read-only audit tool with no output schema, the description is fully sufficient: it details what is scanned, what is returned, and how severity is assigned. The agent can invoke and interpret the result without additional context.

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

  Parameters4/5

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

  Although the schema provides no parameter descriptions for max_age_day, the description explicitly explains its role as the age threshold and default value, making the parameter's semantics clear. It does not detail edge cases like zero or negative values, but the basic meaning is sufficiently covered.

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

  Purpose5/5

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

  The description uses a specific verb ('Audit'), a clear resource ('IAM users'), and a precise condition ('active access keys older than max_age_days'). It unambiguously distinguishes this tool from siblings like audit_users_without_mfa or audit_full_posture.

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

  Usage Guidelines4/5

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

  The description clearly identifies the intended scenario: auditing IAM users for stale active access keys, and explains the threshold and severity logic. It does not explicitly name alternatives or exclusions, but the context is strong enough for an agent to select it appropriately.

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

• audit_users_without_mfaA
  4.7/5.0
  Behavior5/5

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

  Annotations already indicate read-only and non-destructive, and the description adds substantial behavioral detail: it scans every IAM user, considers console login profiles, flags only those with no MFA, reports HIGH severity, and clarifies that non-console users are counted but not flagged. The return object shape is also disclosed.

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

  Conciseness5/5

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

  The description is compact and well-structured: a one-sentence purpose, then a second sentence detailing scan behavior, severity, return shape, and edge-case handling. Every phrase adds value and no irrelevant details are present.

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

  Completeness5/5

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

  For a no-parameter, read-only audit tool with no output schema, the description fully covers purpose, exact behavior, severity, return fields, and the edge case of users without console access. Nothing essential for selecting and invoking the tool correctly is missing.

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

  Parameters4/5

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

  The tool has zero parameters and the schema coverage is 100%, so there are no parameter semantics to document. Per the rubric, a parameterless tool earns a baseline of 4 because no additional description is needed.

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

  Purpose5/5

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

  The description opens with a specific verb-resource-criterion combo: auditing IAM users who can log in to the console without MFA. It differentiates its scope from sibling audit tools by focusing specifically on console login profiles and MFA devices, and includes a concrete severity label (HIGH).

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

  Usage Guidelines4/5

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

  The description gives clear context for when to use the tool: when auditing IAM console access without MFA. It does not explicitly name alternatives or provide when-not-to-use guidance, but the purpose is specific enough that an agent can select it appropriately among the audit_* siblings.

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

• audit_ebs_exposureA
  4.8/5.0
  Behavior5/5

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

  The description deeply explains behavior beyond the readOnlyHint and destructiveHint annotations: it scans all volumes, flags unencrypted volumes as MEDIUM, checks createVolumePermission for public snapshots, flags them CRITICAL, and describes the output dict semantics. No contradiction with annotations exists.

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

  Conciseness5/5

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

  The description is front-loaded with a clear one-sentence purpose, then provides dense but relevant operational details, and ends with a useful return-value summary. Every sentence contributes information the agent needs.

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

  Completeness5/5

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

  For a read-only audit tool with one optional parameter and no output schema, the description is thorough: it covers scope, region fallback, severity mapping, and the return dict structure. An agent can confidently decide when to invoke it and what to expect.

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

  Parameters5/5

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

  Even though schema description coverage is 0%, the description fully explains the only parameter: region defaults to AWS_REGION or us-east-1 when omitted. This adds meaningful behavioral context that the schema alone does not provide.

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

  Purpose5/5

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

  The description states a specific verb ('Audit'), a precise resource ('EBS volumes and snapshots'), and the exact goal ('exposure risks'). It clearly differentiates this tool from sibling audit tools that target RDS, security groups, buckets, and other resources.

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

  Usage Guidelines4/5

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

  The description gives clear context on what the tool scans, how region selection works, and what criteria produce findings. It does not explicitly name alternatives or say 'use this instead of X,' but the resource-specific scope makes the appropriate use case obvious.

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

• audit_trail_postureA
  4.8/5.0
  Behavior5/5

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

  Annotations already mark readOnlyHint=true and destructiveHint=false. The description adds substantial behavioral detail beyond annotations: exact checks performed, the criticality of zero trails, how multi-region trails are handled, severties for each failing check, and the precise return envelope and finding shape.

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

  Conciseness5/5

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

  The description is well-structured with purpose, check list, args, and returns sectioned clearly. The bullets are content-dense and every line provides actionable information, with no redundant phrasing.

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

  Completeness5/5

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

  With no output schema present, the description fully specifies the return envelope, the fields in each finding, severity values, and resource naming. It also explains the default region behavior and the critical zero-trail finding, making it complete for an agent to invoke and interpret results correctly.

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

  Parameters5/5

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

  Schema description coverage is 0%, but the description fully compensates by documenting the only parameter 'region', including its default resolution to AWS_REGION or us-east-1. No other parameter information is needed.

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

  Purpose5/5

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

  States a specific verb and resource: 'Audit CloudTrail trail posture' and enumerates exact checks. The detailed check list makes it unambiguous and clearly distinguishes it from sibling tools targeting RDS, EBS, IAM, or security groups.

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

  Usage Guidelines4/5

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

  The intended use case is clear: audit CloudTrail trail posture in the account. It provides helpful context about scope, including shadow trails, but does not explicitly route the agent away from alternatives such as audit_full_posture or account_security_summary.

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

• audit_world_open_security_groupsA
  4.8/5.0
  Behavior5/5

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

  The description goes far beyond the annotations: it explains the default region resolution from AWS_REGION, the exact CIDRs considered world-open, the severity classification for sensitive ports, and the full return dict shape with each key's meaning. This provides rich operational context that annotations alone do not convey.

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

  Conciseness5/5

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

  The purpose is front-loaded and each sentence adds operational detail. The layout clearly separates scope, severity criteria, and return value. It is long but every part is necessary for correct invocation and interpretation.

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

  Completeness5/5

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

  There is no output schema, so the description fully documents the return value including the fields in each finding. It also covers region behavior, scanning scope, and severity rules. Nothing essential is missing for an agent to select and invoke this tool.

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

  Parameters5/5

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

  The only parameter, region, has no schema description, but the description fully compensates: it explains that region defaults to null, falls back to AWS_REGION, and then to us-east-1. This is exactly the semantic detail an agent needs to call the tool correctly.

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

  Purpose5/5

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

  The description states a specific verb ('Audit'), a specific resource ('EC2 security groups'), and a precise criterion (ingress rules open to the world). This clearly distinguishes it from sibling audit tools like audit_public_buckets or audit_ebs_exposure.

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

  Usage Guidelines4/5

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

  The description makes it clear when this tool is relevant: when you need to audit security groups for world-open ingress. It also explains region selection behavior. It does not explicitly name alternative tools or exclusions, but the purpose is so specific that an agent can infer appropriate use.

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