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

No annotations are present, so the description carries the full behavioral disclosure burden. It does so well: it states the multi-level output shape, explains automatic warnings and their trigger conditions, and clarifies the JSON return format. The 'BEFORE modifying' framing also implies this is an analysis operation rather than a mutation.

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 appropriately sized and front-loaded with the highest-value instruction: call this before modifying a public interface. The bulleted sections are dense and non-redundant; each line adds operational 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?

With no output schema, the description correctly explains the return value and warning behavior, so an agent can anticipate the response. It is slightly incomplete on parameter mechanics—particularly element_path syntax and the optional model_id behavior—but the schema helps with model_id, and the core workflow is well covered.

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?

Context signals report 0% schema description coverage, so the description must compensate. It partially does by showing that the element can be a function, class, or deletable code, but it never names element_path or explains how to format it, and model_id is addressed only in the schema. This is meaningful but incomplete compensation.

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 uses a specific verb-resource pair: analyzing change impact before modifying a public interface. It clearly distinguishes itself from sibling tools by promising all abstraction levels at once, so an agent can tell it apart from get_element_dependencies or get_element_structure without opening schemas.

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 explicit when-to-use scenarios: before changing signatures, renaming classes, deleting code, or planning large refactoring. It does not explicitly list when-not-to-use cases or name alternative sibling tools, so it falls just short of a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains what the tool returns ('JSON with cycles, hub modules, and summary metrics') and hints at heavier usage via 'occasional reviews, not daily use.' It does not explicitly state whether the tool is read-only, how expensive it may be, or what data/model prerequisites exist, so some behavioral transparency is 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, front-loaded with purpose and usage, and uses bullets and examples to make each point immediately actionable. Every sentence adds value, and there is no redundant filler.

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 covers the main checks, aggregation semantics, and return shape, which is a solid baseline. However, it does not explain the model_id or scope_path parameters in prose, nor does it clarify how this tool relates to siblings like sgraph_security_audit or sgraph_analyze_change_impact. Given the absence of annotations and an output schema, a bit more context would be needed for fully confident 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 description adds meaningful context for the checks and aggregation_level parameters, going beyond the schema by explaining granularity levels with examples (2 = coarse/monorepos, 3 = default, 4+ = deeper nesting). The schema also includes descriptions for checks, model_id, scope_path, and aggregation_level, so this dimension is well covered even though the top-level parameter has no direct description.

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 with a specific verb and resource: 'Run architectural health checks on the codebase.' It also lists the available check types ('cycles', 'hubs') and explains their meaning. It does not explicitly contrast itself with sibling tools like sgraph_security_audit, which would make the differentiation stronger.

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 clear usage context: 'For occasional reviews, not daily use.' It also gives practical guidance on aggregation_level values, including which one is good for monorepos. However, it does not explicitly say when NOT to use this tool or mention alternatives such as sgraph_security_audit for security-specific checks.

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 of behavioral disclosure, and it does so thoroughly. It documents the read-only constraint, what the graph mapping looks like, how relationships are represented, the performance trade-offs of include_hierarchy, that results are returned as a JSON array, and that initial indexing may take seconds on large models. This is unusually transparent for a tool description.

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 long but well-structured and front-loaded. The first sentence states the core behavior, followed by usage guidance, graph schema information, examples, performance notes, and return format. Every section adds value needed to use the tool correctly; the examples are illustrative rather than redundant. This is appropriate density for a complex query tool, not padding.

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 tool is complex, has no output schema, and has no annotations, yet the description covers all essential invocation concerns: what the model is, how to write queries, relationship types, property names, hierarchy behavior, performance expectations, return format, and read-only constraints. An agent has enough information to construct and run a correct openCypher query without external documentation.

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 top-level schema reports 0% description coverage, so the description must compensate. It does so substantially by explaining the query language, node/relationship mapping, property conventions, and hierarchy behavior. It does not explicitly explain the `limit` safety parameter or `model_id` optionality, but the schema itself describes those fields, and the examples demonstrate how to write valid queries. This is strong compensation but not exhaustive.

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 opens with a specific verb and resource: 'Run an openCypher query against the loaded model.' It goes beyond a tautology by explaining what the tool expresses — multi-hop paths, aggregation, complex filtering — and explicitly differentiates itself from other tools by noting these are queries 'the other tools can't express.' The mapping to a labeled property graph and example queries make the purpose unmistakable.

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 when to use this tool: 'Use this tool for complex graph queries that the other tools can't express,' followed by concrete categories. It also gives exclusions, telling users that CREATE/DELETE/SET are not supported and that include_hierarchy=false is the recommended default unless parent-child traversal is needed. This gives the agent clear selection criteria relative to 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?

With no annotations, the description carries the behavioral burden and does disclose the return shape: element info plus flat key-value attributes, and only attributes that exist on the element. It implies a read-only inspection operation through 'Get' and 'Inspect', though it does not explicitly state read-only behavior or failure/auth conditions.

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 compact and front-loaded: a one-sentence purpose, a scannable When-to-use bullet list, then two short sentences about return behavior. No sentence is redundant or filler.

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 single-required-parameter metadata getter with no output schema, the description covers when to use it, what attributes are returned, and how the result is shaped. It still leaves path-format and optional-model mechanics to the schema and does not route the agent to sibling tools for path resolution, but the essentials for selection and invocation are 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?

Context signals report no effective schema-description coverage, so the tool description must compensate for parameter understanding, but it never explains how to fill element_path or the optional model_id. The attribute examples (loc, risk_density, secret_type) clarify the return payload, but they do not address how to invoke the tool with the correct path/model.

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 opens with a precise verb and object: 'Get all attributes (metadata) of a code element,' and the When-to-use list grounds it in concrete attribute categories (quality metrics, ownership, security markers). This scope contrasts with sibling tools like sgraph_get_element_dependencies and sgraph_get_element_structure, so an agent can distinguish it.

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 'When to use' section gives four concrete contexts for choosing the tool, including a general rule to inspect metadata before deeper analysis. It stops short of naming sibling alternatives or stating when not to use it, so it misses full alternative/exclusion 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 the full burden and does so well: it explains abstraction behavior via result_level, descendant handling, filtering semantics, and includes a performance warning about large result sets. It also states the return format as JSON dependency lists, giving the agent a clear expectation.

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 longer than average but well-organized into scannable sections. The 'THE KEY TOOL' phrase is unnecessary fluff, and the target_filter example is somewhat repeated in the later full example, but overall the length is justified by the tool's complexity.

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 complex dependency-query tool with no annotations and no output schema, this description is remarkably complete: it gives use cases, parameter semantics, a performance caveat, a concrete dependency-check example, and the expected return shape. There is little an agent needs to infer on its own.

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?

Even though schema-level description coverage is reported as 0%, the description richly explains the parameters: direction values with meanings, result_level meaning at different levels, include_descendants behavior, and target_filter usage with a concrete example. It adds real operational meaning beyond field names.

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 states a specific verb and resource ('Query what code depends on an element, or what it depends on') and then clarifies the two directions. It is easily distinguished from siblings because it focuses specifically on dependency relationships and even explains incoming vs outgoing semantics.

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 strong 'When to use' guidance with concrete scenarios: modifying a function, understanding a class, planning refactoring, and checking module dependencies. It does not explicitly name alternatives or state when not to use this tool, so it falls short of full exclusionary 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 provided, the description carries the full burden. It discloses that the tool does not read source code, that it returns a JSON hierarchy with path, type, name, and children, and that it is 'much cheaper than Read.' It stops short of explicitly saying the operation is non-destructive, though 'Explore' and 'without reading' strongly imply read-only 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 organized in clear, purposeful sections: purpose, when-to-use, max_depth explanation, return format, and cost guidance. Every sentence earns its place, with no filler or redundant restating of the tool name.

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 provides enough to invoke the tool correctly: the starting path, depth control, and the shape of the returned JSON hierarchy. It lacks example paths, error behavior, or mention of model_id, but for a read-only exploration tool with only one required parameter, 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 description adds meaningful semantics to max_depth by explaining the three levels with concrete examples (file->classes, file->classes->methods, deeper nesting rarely needed). It also implies element_path semantics by describing files/directories/classes. However, model_id is not mentioned anywhere in the description, though it is optional and defaulted to null.

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 opens with a specific verb and resource: 'Explore what's inside a file, class, or directory WITHOUT reading source code.' It clearly distinguishes the tool from reading source code and from sibling tools like sgraph_search_elements or sgraph_get_element_dependencies by focusing on structural containment. The purpose is immediately obvious even before opening the schema.

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 'When to use' section explicitly lists concrete scenarios: inspecting file contents instead of Read+scroll, exploring directories instead of ls+recursion, and understanding class methods before implementation. It also tells the agent to 'use this first to decide what to read,' providing clear routing guidance relative to cheaper 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?

With no annotations, the description carries the behavioral burden. It usefully discloses that the tool returns an ID and is idempotent when the model was auto-loaded at startup, but it does not state whether a load overwrites existing state, whether the operation is mutating, or what error conditions can occur.

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?

Two concise sentences front-load the core action and output, then cover the conditional auto-loaded behavior. There is no filler, repetition of schema fields, or unnecessary detail.

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 one-parameter tool with no output schema, the description captures the essential call contract: provide a file path, receive an ID, and handle the already-loaded case. It omits file-format and error-behavior details, but the core usage context is sufficiently complete for a tool of this low 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 coverage is 0%, so the description must compensate for the single 'path' parameter. 'Load ... from file' clarifies that the path identifies a file location, but it adds nothing about accepted file formats, path resolution, or restrictions. This is minimal but adequate for a single self-descriptive 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 names a specific verb ('load'), a precise resource ('graph model'), and the source ('from file'), and it states the output (an ID for subsequent queries). It is clearly distinct from its siblings, which all query or analyze an already-loaded model.

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 phrase 'for subsequent queries' frames the tool as the entry point before using other graph operations, and the auto-loaded note tells agents when calling it may be a no-op. It does not explicitly list exclusions or alternatives, but no sibling performs loading, so there is no competing tool to rule out.

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 disclosure burden. It clearly states the return type: 'Returns a filtered model (elements + associations), not tabular data' and specifies the JSON shape. It also documents case-sensitive and case-insensitive matching behaviors. It stops short of explicitly stating that the tool has no side effects, though 'query' and 'filter' imply a read-only 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 long but every section earns its place: a query language reference requires syntax examples and operator explanations. The purpose and return type are front-loaded, and the syntax reference is clearly organized with headings. It is dense but not padded.

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 complex tool with no output schema and no annotations, the description is remarkably complete: it explains syntax, operators, examples, and return structure. It does not cover edge cases, error behavior, or how model_id interacts with the default model, but these are minor for selecting and invoking 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 description adds substantial meaning to the expression parameter, offering a full syntax quick reference with element selection, attribute filters, dependency queries, logical operators, and examples. The optional model_id parameter is adequately explained in the schema itself, so the description's focus on the required expression parameter is appropriate.

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 opens with a specific verb and resource: 'Filter the model using SGraph Query Language' and lists concrete use cases: filtering sub-models, checking module dependencies, and attribute-based element selection. It also explicitly contrasts the tool with sgraph_cypher_query, making the distinction clear.

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 'Best for' and explicitly directs users needing tabular queries and aggregation to sgraph_cypher_query instead. It also gives query-category examples that clarify when this tool is appropriate versus structural 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the mapping is configured in sgraph-mapping.json, shows the default path mapping pattern, and discloses the 'exists' field indicating whether the file/directory is present locally. This makes the operation's behavior reasonably transparent, though it does not explicitly state side effects or error behavior for unmapped paths.

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 core action and purpose, then organized into useful sections: when to use, mapping configuration, return values, and next step. Every section earns its place and no redundant filler is present.

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 one-parameter mapping tool with no output schema, the description covers the important aspects: purpose, when to use, path mapping behavior, and return fields. It could be more complete by stating what happens when a path cannot be resolved or when the mapping file lacks an entry, but the provided information is sufficient for most use cases.

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. It indirectly explains the sgraph_path format via the default mapping template '/Organization/<category>/<repo>/...' and the return field 'sgraph_path: Original path'. This adds useful context, but it does not directly describe the parameter's valid formats, required prefix, or behavior for invalid paths.

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 opens with a specific action and resource: 'Map sgraph path to local filesystem path.' It immediately states the intended purpose ('find source code for NuGet packages'), which clearly separates it from sibling tools that search, load, or analyze graph elements.

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 an explicit 'When to use' section with concrete scenarios, such as needing to read source code after finding a class/method in sgraph. It also gives a follow-up directive to use the Read tool. However, it does not mention when not to use this tool or name alternative tools that might be preferable.

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 behavioral burden. It usefully discloses that scope defaults to the server default when available, that model_id can be omitted to use an auto-loaded model, and that the response is JSON with a match count and element list. It does not explicitly mention truncation or result limits, but the search semantics are otherwise 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 a one-sentence summary, a focused 'When to use' list, a compact parameter breakdown, and a clear return line. There is no fluff, and the most important scoping 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 no output schema and no annotations, the description should be fairly self-sufficient. It covers purpose, usage, and core parameter behavior, but it misses the max_results parameter and does not explain that results may be truncated by that limit, which is relevant for the 'find all implementations' use case. The return value is described only as a count and element list, with no detail about element shape.

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 adds helpful semantics for query, scope_path, element_types, and model_id, going beyond bare schema labels with wildcard/regex/substring examples. However, it omits max_results entirely, and it lists "dir" as a valid element_types value while the schema says "directory," creating a potential incorrect invocation.

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 opens with a specific verb and resource: "Find code elements by name pattern." It clearly distinguishes this tool from generic text search by saying "Use instead of grep for precise symbol lookup," and the positioning relative to dependency queries is explicit in the usage bullets.

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 'When to use' section gives three concrete, actionable scenarios: locating a symbol by name, finding pattern matches like *Service*, and resolving a symbol before querying dependencies. It provides clear context but does not explicitly state when not to use it or name sibling tool alternatives, so it falls just short of a 5.

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

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

With no annotations, the description carries the burden of behavioral disclosure, and it does a solid job: it explains the inclusion rule ('only those with findings are included'), defines each dimension's meaning, and states that the return is JSON with a summary plus per-dimension breakdown. It does not explicitly state read-only behavior or permissions, but 'Security overview' strongly implies a non-mutating audit.

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 core purpose, then uses a scannable bullet list for the six dimensions, and closes with a one-line output summary. No sentence is wasted, and the structure helps an agent parse the behavior quickly.

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 enough for an agent to know what the tool returns and which security aspects it covers, even without an output schema. It could be stronger by explaining how scope_path and model_id affect the results, but those fields are at least documented in the nested schema, so the gap is moderate rather than severe.

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's prose never explains top_n, model_id, or scope_path, and the context signal reports 0% schema description coverage for the top-level parameter. The nested schema entries do contain descriptions for the individual fields, but the tool description itself does not compensate for the low coverage by explaining how these inputs affect the audit.

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 opens with a concrete resource: a security overview across six explicitly named dimensions, which is specific enough for an agent to recognize its function. It does not explicitly contrast itself with the sibling sgraph_audit, but the security-specific focus and dimension list make its purpose reasonably distinct.

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 gives clear usage contexts: 'organizational security posture, audit preparation, risk prioritization.' It does not mention when not to use it or name alternative sibling tools, so it earns a 4 rather than a 5.

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