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

No annotations are present, so the description must carry the behavioral burden. It only names a topic and does not disclose whether the tool returns a report, list, diagram, or performs any action. This is effectively transparent about nothing.

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 wording is very compact and front-loaded, with no filler words. It is more of a labeled fragment than a full sentence, but it is efficient and scannable for a zero-parameter 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?

There is no output schema and no annotations, so the description should clarify what the agent will get. It only lists content areas and does not explain the return format, size, or how the information is presented, leaving important invocation context missing.

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 zero parameters and the input schema is empty, so there are no parameter semantics for the description to add. Applying the 0-parameter baseline, the description does not need to explain 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?

The description identifies the broad domain ('Architecture') and lists the topics it covers: subsystems, cross-subsystem dependencies, and language mix. However, it lacks a main verb and does not clearly distinguish itself from sibling tools such as lilbrain_subsystem, lilbrain_overview, or lilbrain_dataflow.

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 no guidance on when to use this tool versus alternatives, and no exclusions are stated. It implies an architecture-focused purpose but never explains how it differs from the many related 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 full burden of behavioral disclosure. It correctly exposes the non-obvious behavior that the tool does not perform a fixed analysis itself but auto-routes to an appropriate internal analysis tool. It does not mention output shape or ambiguous-question handling, but the core trait is 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?

Two short sentences earn their place: the first states the purpose, the second states the distinguishing behavior. There is no redundant filler, and 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?

For a one-parameter tool with no output schema and no annotations, the description covers the essential context: domain (codebase), input language (natural language), and behavior (auto-routing). An example or return-format note would help, but nothing needed for a correct first call is missing.

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 already documents the single required parameter with 100% coverage ('Question in plain English'). The description adds that the question should be about the codebase and that it will be auto-routed, which is useful but marginal. Baseline 3 applies because the schema carries the parameter meaning.

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?

States a distinct verb ('Ask') and resource ('the codebase'), and characterizes the tool as a natural language interface that auto-routes to the right analysis tool. This clearly differentiates it from the many specific sibling tools, which are named analysis operations rather than a general entry point.

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 clear context for use: an agent with a natural language question about the codebase can use this tool without needing to know which specialized sibling to invoke. It does not explicitly list when to avoid it or name specific alternatives, but the auto-routing behavior covers the selection decision.

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 does convey the read-only analytic nature of the tool and the two directions of the call graph, but it does not explain return format, whether the graph is direct or transitive, or any limitations.

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 a single compact sentence with no filler. It front-loads the core concept and efficiently conveys both callers and callees without wasted words.

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 tool, the description is minimally adequate, but the absence of annotations, output schema, and usage guidance leaves important context to inference. With many closely related siblings, an agent would benefit from more direction about what this tool uniquely provides.

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 already describes 'name' as 'Function name' with 100% coverage. The description adds only that the target is a function and that callers/callees are returned, which provides context but no additional parameter format or qualification requirements.

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 clear analytic resource: a call graph for a function, including both callers ('who calls it') and callees ('what it calls'). It is understandable but doesn't explicitly differentiate from sibling tools like lilbrain_trace or lilbrain_dataflow.

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 no guidance on when to use this tool instead of the many related siblings like lilbrain_overview, lilbrain_impact, or lilbrain_trace. It implies a function-focused call graph use case but provides no exclusion criteria or alternative selection hints.

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 does disclose the detection method (token similarity) and high-level goal, but it does not describe the output format, side effects, scope, or how the threshold affects behavior. This is adequate but not rich.

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

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

The description is two short, information-dense sentences with no filler. The main action and method are front-loaded, and the second sentence reinforces the practical use case.

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 tool with one optional parameter, the description plus schema is mostly sufficient for an agent to select and invoke it. The main missing piece is the result/return behavior—since there is no output schema, a brief note on what the tool returns would make it fully 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?

Schema coverage is 100%; the threshold parameter is already well documented in the input schema with type, range, and default value. The description adds nothing about the parameter beyond what the schema provides, so the baseline of 3 applies.

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 ('Detect'), a clear resource ('near-duplicate functions'), and a precise method ('using token similarity'). It clearly distinguishes this tool from sibling code analysis tools like lilbrain_deadcode or lilbrain_semantic by stating its exact detection goal.

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 should be used when looking for copy-paste or near-duplicate code, but it never explicitly says when to use this tool versus alternatives. With over 20 sibling tools, the lack of routing guidance is a clear gap.

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 behavioral burden. It discloses that the tool performs complexity analysis and supports both per-function detail and top-N ranking, which implies a read-only analytical operation. However, it does not clarify what the ranking is based on beyond complexity, whether results are scored, or what 'per-function detail' includes.

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 a single, tightly packed sentence with no filler. It front-loads the core metrics and then states the two invocation modes, making it easy to scan and quickly understand the tool's 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?

For a simple two-parameter tool with no annotations and no output schema, this is minimally adequate: an agent can infer that omitting name yields a default top-N ranking and that providing name yields per-function detail. However, it lacks detail about output shape, how n and name interact if both are provided, and how this differs from complexity_velocity.

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 100%, so the baseline is 3. The description's 'per-function detail or top-N ranking' wording loosely maps to the name and n parameters, but the schema already explains those fields explicitly. The description adds no meaningful semantic information beyond that.

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 identifies the tool as delivering cyclomatic and cognitive complexity analysis, with two modes: per-function detail or top-N ranking. It names specific, non-generic resource types and metrics, though it does not explicitly contrast itself with the closely named sibling lilbrain_complexity_velocity.

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?

There is no guidance on when to use this tool versus alternatives such as lilbrain_hotspots or lilbrain_complexity_velocity. The description implies a complexity-analysis use case but never states exclusions, preferred scenarios, or when another sibling 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 are provided, so the description carries the full burden of behavioral disclosure. It says the tool tracks and shows complexity-related commit information, but it does not explicitly state that the operation is read-only, whether a git repository is required, what complexity metric is used, or what the output looks like.

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 short sentences with no filler. The core purpose is front-loaded, and the second sentence adds a concrete sense of the output without repeating the tool name or the 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?

The tool is simple: one optional parameter, no output schema, and no annotations. The description is enough for an agent to understand when it might be useful and to invoke it with defaults, but it omits details about the return format, the meaning of 'complexity', and any prerequisites like a git repository.

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 100%, and the only parameter, n_commits, is already described as 'Number of commits to analyze (default 10)'. The tool description adds no additional parameter semantics, which matches the baseline for fully covered schemas.

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 clear action and resource: it tracks complexity changes and shows which commits touched complex code. It is not a tautology and the git-history scope makes its purpose understandable, though it does not explicitly contrast itself with siblings like lilbrain_complexity or lilbrain_hotspots.

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 intended use is implied: use this tool to see complexity changes across recent commits. However, there is no explicit when-to-use guidance and no mention of alternatives or when not to use it, so the agent must infer usage from the purpose statement.

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 the full burden of describing behavior. It does disclose the core read-only behavior: showing upward callers and downward callees. However, it does not clarify whether relationships are direct or transitive, whether exact name matching is required, or what the result shape is.

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 a single tight sentence with the core scope front-loaded. The 'Data flow:' prefix is slightly redundant with the tool name, and no additional detail is provided, but there is no wasted or misleading 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 one-parameter read-only query, the description identifies both the input and the conceptual output, so it is minimally usable. However, with no output schema and no annotations, it should explain more about result granularity, depth of the call graph, and naming requirements to be considered 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 already fully documents 'name' as 'Function name', giving 100% schema coverage. The description adds only 'for a function', which essentially restates the schema. Since the schema does the heavy lifting, the baseline of 3 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 clearly identifies the resource (a function) and the returned content (upstream callers and downstream callees), which distinguishes it from single-direction sibling tools like lilbrain_callers. It lacks an explicit action verb like 'show' or 'list', but the meaning is still specific and not a tautology.

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 should be used when a function's call relationships in both directions are needed, but it never states this explicitly or mentions alternatives such as lilbrain_callers. The usage context is inferable from the wording, but an agent is given no direct when-to-use or when-not-to-use 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 it delivers: it states the detection criterion (zero callers), the organization (grouped by subsystem), and an output dimension (LOC waste estimate). It does not discose limitations or how staleness is handled, but for a read-only analysis tool this is strong behavior 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?

One concise, front-loaded sentence with no filler. 'Find dead code' leads, and the operational definition and output details follow immediately. Every part of the sentence earns its place.

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 zero-parameter, no-output-schema tool, the description is sufficiently complete: an agent knows what to invoke it for, what counts as dead code, how results are organized, and what quantitative estimate to expect.

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?

There are zero parameters, so the schema offers nothing to explain; the description does not need to add parameter semantics. Per the rubric, a zero-parameter tool earns a baseline of 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?

Description uses a specific verb and resource: 'Find dead code' concretely defined as 'functions with zero callers.' It also names two output features—subsystem grouping and LOC waste estimate—that make the tool's purpose unmistakable and distinct from sibling tools like lilbrain_callers or lilbrain_overview.

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 context for when this tool is appropriate: when dead code detection is needed, and it precisely scopes that to functions with no callers. It does not explicitly name alternatives or exclusions, but for a zero-parameter tool the intended use is obvious.

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 available, the description carries the burden of behavioral disclosure. It does state the core behavior: automatically generating Mermaid or D2 architecture diagrams. But it does not clarify whether the output is raw diagram source text, a rendered artifact, or how invalid or missing target names are handled, so the behavior is only partially 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 short, front-loaded with the action and output formats, and every sentence adds useful information. The second sentence is formatted like parameter documentation rather than prose, which is slightly awkward but not wasteful.

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 tool with zero required parameters and a clear purpose, the description is minimally viable. However, with no output schema and no annotations, it leaves open what the return value looks like, how targets are located, and what error cases exist; given the low complexity this is a moderate gap rather than a severe one.

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 100% for both optional parameters, so the baseline is 3. The description mostly repeats the schema's target semantics rather than adding new meaning, and it offers no additional detail about format values or target resolution beyond the schema's enums and type 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 a specific action ('Auto-generate') and resource (Mermaid or D2 architecture diagrams), and it describes the accepted target scopes: architecture, subsystem, or function. It is not tautological, but it does not explicitly differentiate itself from sibling tools such as lilbrain_architecture or lilbrain_subsystem by naming when to choose it over them.

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 target line gives implied usage guidance: to get a diagram, pick an architecture, subsystem, or function target. However, it never states when to prefer this tool over sibling tools or what conditions make another tool more appropriate, so usage context is only implied.

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 burden of explaining behavior. It communicates that this is an analytical diff operation and lists output dimensions, but it leaves implied that the operation is read-only and does not describe the shape of the result or any environment 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?

One concise sentence leads with the core operation, then lists the valuable output categories. There is no redundant wording 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?

The tool is simple: two optional, well-documented parameters and no required inputs. The description explains the main outcome at a useful level, though without an output schema, a bit more detail about the exact return format would make it fully 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?

Schema coverage is 100%, with base and head already described and defaulted. The description's 'between any two refs' aligns with these parameters but does not add meaningful detail beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific operation—git-aware graph diff—and names its key outputs: changed functions, blast radius, and risk level. This is clear enough to identify the tool's purpose, though it does not explicitly differentiate it from nearby siblings like lilbrain_impact or lilbrain_pr_review.

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 'between any two refs' gives clear context for when the tool applies: comparing arbitrary git references. It does not provide exclusions or name alternative 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, the description carries the full burden for behavioral disclosure. It conveys the core behavior—querying across multiple codebases—and 'query' suggests a read-oriented operation, but it does not describe result shape, federation/merge behavior, or side-effect guarantees. This is adequate but leaves meaningful gaps.

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 a single, front-loaded sentence with a colon-separated definition and no filler. Every word contributes meaning, making it concise without sacrificing 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?

The tool is relatively simple, with only two documented parameters and no nested objects, so a lengthy description is not required. However, because there is no output schema and no annotations, the description omits what the response contains and any operational caveats about federated search. It is sufficient for basic selection and invocation but not fully 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?

Schema description coverage is 100%, so the input schema already documents both the 'query' and 'repos' parameters. The description does not add parameter-level detail beyond reinforcing the multi-repo scope, which matches the baseline of 3 when the schema handles 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 a specific action ('query') and resource ('multiple codebases'), and the 'multi-repo federated' qualifier helps distinguish it from single-repo search siblings like lilbrain_search. It is not a tautology, but it does not explicitly name or contrast any sibling tool, so it stops short of a 5.

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 'query across multiple codebases at once' implies the tool should be used when an agent needs to search several repositories in a single operation. However, there is no explicit when-to-use versus alternatives or when-not-to-use guidance, leaving the usage context implied rather than 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It implies a read-only lookup and names the output categories, but it does not mention path matching behavior, missing-file errors, index freshness, or whether this is purely a structural summary versus a file read. This is modest transparency with no contradiction.

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 one sentence, front-loaded with the action and resource, and each listed category (functions, classes, sections, language) adds useful specificity. There is no filler or repetition.

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-parameter read-only tool, the description names the main return categories and makes the basic invocation understandable. However, with no output schema and no differentiation from many closely related sibling tools, an agent still lacks guidance on the exact return shape and when this tool is the right choice.

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 100%, and the schema already documents 'path' as 'File path (relative or partial)', so the baseline applies. The description does not add further parameter-level meaning beyond indicating what kind of information the path will be used to retrieve.

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 concrete verb ('Get info') tied to a specific resource ('a file') and enumerates the returned aspects: functions, classes, sections, language. It is clear on its own, but it does not explicitly contrast itself with siblings like lilbrain_read or lilbrain_function, so it stops short of full differentiation.

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?

There is no guidance about when to prefer this tool over lilbrain_read, lilbrain_function, lilbrain_overview, or other siblings. No alternative conditions or exclusions are given, so the intended selection context must be inferred from the name and output list.

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. It clearly states the return contents, but it does not confirm the operation is read-only, how name matching behaves beyond the schema's 'exact or partial', or whether results are bounded in any way.

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?

A single, dense sentence communicates the operation, the input, and all relevant output aspects. There is no filler or 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?

For a one-parameter lookup tool with no output schema, the description covers the essential input and return fields. It is slightly incomplete only because it does not compare itself with the many sibling lookup tools, leaving the agent to infer the boundary between function lookup and search/overview 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?

Schema description coverage is 100%, so the schema already documents the single 'name' parameter. The description adds little beyond the schema, only reinforcing that the lookup is by function name.

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?

States a clear verb ('Look up'), a specific resource ('any function by name'), and enumerates the output fields (signature, location, callers, callees, language). It is distinguishable from the more specialized sibling tools like lilbrain_callers, though it does not explicitly name that distinction.

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 when you have a function name and want comprehensive function-level metadata. However, it does not explicitly state when to prefer lilbrain_function over lilbrain_callers, lilbrain_search, or lilbrain_file, 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 behavioral burden. It does disclose the core selection metric (fan-in + fan-out), which is the main behavioral trait. However, it does not mention output format, pagination, limitations, or whether the operation has side effects; for a read-only analysis tool this is a moderate gap.

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 a single, focused sentence with no filler. It front-loads the key idea and every word contributes to understanding what the tool does.

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 tool with one optional parameter and no output schema, the description gives the essential answer: the tool returns the most connected functions by fan-in + fan-out. The schema handles the count and default. The main missing piece is routing relative to sibling tools, but that is captured under usage guidelines.

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 schema covers 100% of the single optional parameter n, including its default value, so the description does not need to add parameter details. The baseline of 3 applies because the description provides no extra 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 identifies the resource (functions) and the selection criterion (highest fan-in + fan-out), which distinguishes it from sibling analysis tools like lilbrain_complexity or lilbrain_callers. However, it lacks an explicit verb such as 'list' or 'show', so it reads as a noun phrase rather than a full action statement.

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 what the tool computes but gives no guidance on when to use it instead of related siblings such as lilbrain_complexity, lilbrain_callers, or lilbrain_impact. No selection context, exclusions, or alternative routing is provided, leaving the agent to infer appropriate usage.

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

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

With no annotations provided, the description must carry the behavioral disclosure burden. It does reveal that the tool computes affected callers, subsystems, and risk level, which is meaningful. However, it does not disclose whether this is purely read-only, how depth affects results, or any limitations of the analysis.

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?

A single, well-constructed sentence that immediately communicates the tool's purpose. The 'Blast radius' framing is efficient and memorable, and the listed outputs are front-loaded without any wasted words.

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 there is no output schema, the description usefully names the key return categories: affected callers, subsystems, and risk level. It does not describe return structure or detailed operational behavior, but for a selection-and-invocation context the description is largely sufficient, especially with the schema documenting the depth parameter.

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 covers 100% of parameter descriptions: 'Function to analyze' for name and 'Max caller depth (default 5)' for depth. The tool description does not add extra semantics beyond the schema, so the baseline score of 3 applies.

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

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

The description clearly identifies the tool's purpose: analyzing blast radius when changing a function. It explicitly names the affected outputs (callers, subsystems, risk level), which distinguishes it from sibling tools like lilbrain_callers that likely only show direct callers.

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 change-impact analysis ('if you change this function, what breaks?'), but it does not explicitly state when to choose this over alternatives or mention exclusions. No sibling tool is named as a comparison, leaving some inference required.

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 behavioral disclosure burden. It adds useful scope details—files, functions, classes, languages, subsystems, pipelines—and signals an entry-point summary role, but it does not describe output format, size, or whether it returns any computed insights. This is adequate but not deeply 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 two short sentences with no filler. 'Project overview' is front-loaded, the coverage list is compact, and 'Start here' adds immediate usability.

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 zero-parameter overview tool, the description adequately covers what the tool returns and how to begin using it. It does not describe the output structure, but no output schema is present and the tool's purpose is simple enough that this is a minor gap.

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 accepts zero parameters, so there are no parameter semantics to clarify. The empty schema needs no compensating explanation, and the baseline of 4 applies.

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 it provides a project overview covering files, functions, classes, languages, subsystems, and pipelines, which clearly identifies the resource and scope. It lacks an explicit verb like 'get' or 'list', but 'overview' and 'Start here' make its entry-point role clear and help distinguish it from the more specific sibling 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?

'Start here' explicitly tells an agent this tool is the initial exploration entry point. It does not enumerate when to use alternatives, but for a zero-parameter overview tool, this is reasonable and actionable 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 the full burden of behavioral disclosure. It states the operation is to 'trace' but does not explicitly say whether this is read-only, what output or trace format the agent should expect, whether it searches the codebase, or what limitations 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 one concise sentence that front-loads the core action and resource. Every word contributes to the meaning, with no filler or redundant restatement 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?

Despite having only one required parameter, the tool exists alongside many similar analysis siblings, including lilbrain_trace, and the description does not explain what a 'trace' returns or how the tool behaves. With no output schema and no annotations, the description is too sparse to fully guide an agent in selecting and invoking it 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 single parameter `name` is already fully described in the schema as 'Pipeline name', and schema coverage is 100%. The description adds value by saying 'or pattern' and listing examples like parse, validate, handle, and compile, which helps the agent understand what kinds of names are acceptable beyond a literal pipeline name.

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 ('Trace') and a clear resource ('named pipeline or pattern') with illustrative examples (parse, validate, handle, compile), so an agent can identify the general purpose. However, it does not explicitly distinguish this tool from the sibling lilbrain_trace, which also uses 'trace' in its name.

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 should be used when the agent needs to trace a pipeline or pattern, but it gives no explicit guidance on when to choose this over lilbrain_trace, lilbrain_function, or other siblings. No exclusions or alternative conditions 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?

With no annotations, the description carries the behavioral burden. It discloses what the tool computes (changes, blast radius, complexity delta, risk), but does not explicitly state whether it is read-only, whether it performs network calls, or whether it has side effects. The word 'auto-generate' implies non-destructive analysis, but this is not confirmed.

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 a single efficient sentence that front-loads the action and then lists key outputs. It earns its place without fluff, though the term 'context' is slightly vague and could be more precise.

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 tool with one optional parameter and no output schema, the description covers the main outputs but omits details like how the base branch interacts with the result, what the return format looks like, and how this differs from closely related siblings. It is adequate but leaves some gaps for an agent to resolve.

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 100% because the single parameter base_branch has a description. The tool description itself adds no parameter-level detail, but the schema adequately documents the default value and purpose, so the baseline 3 applies.

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 states a specific verb ('Auto-generate') and resource ('PR review context') and enumerates concrete outputs (changes, blast radius, new cross-subsystem edges, complexity delta, risk). It is clear about what the tool produces, though it does not explicitly differentiate it from siblings like lilbrain_diff or lilbrain_impact.

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?

There is no guidance on when to use this tool versus the many sibling tools. It implies use for PR review, but does not state exclusions or alternatives, leaving the agent to infer when lilbrain_diff, lilbrain_impact, or lilbrain_complexity 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?

With no annotations, the description carries the burden of behavioral disclosure. It does disclose that the operation is a read and indicates what input modes are supported, which is meaningful. However, it does not explain behavior around ambiguous names, missing line ranges, or return format.

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?

This is a single, efficient sentence that front-loads the verb and resource and covers both supported modes without filler. Every word earns its place.

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?

Adequate for a simple read tool, but the two-mode design leaves a real ambiguity: start and end are optional in the schema, yet the description implies a file region requires both. There is also no output-schema and no guidance on what happens when reading a bare file path.

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 already covers all three parameters with meaningful descriptions (name as function/path, start/end for file reads), so the description does not need to add much. The mode-level framing adds mild clarity but no new detail about defaults, formats, or edge cases.

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 ('read') and a specific resource ('source code') with two clear modes: function by name and file region by path plus line range. It is clear and self-contained, but it does not explicitly contrast itself with sibling tools such as lilbrain_function or lilbrain_overview.

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 when-to-use versus alternatives guidance is provided. The description implies reading raw source code is the use case, but it never states when this tool should be preferred over sibling tools or when it should be avoided.

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. 'Correlate' and 'find' clearly signal a read-only analysis operation, which helps, but it doesn't disclose any behavioral details such as input precedence between trace_dir and trace_file, whether it requires at least one parameter, or what kind of output it returns. It avoids contradictions but leaves operational behavior under-specified.

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 sentences, no wasted words, and the core purpose is front-loaded. It conveys the essential idea and key outcome without bloat or repetition.

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?

This is a complex analysis tool with no output schema and two optional parameters. The description doesn't explain what the tool returns, whether one of trace_dir/trace_file is needed, how the correlation is performed, or how results should be interpreted. Given the absent output schema and the general-purpose sibling set, more operational context is required for an agent to invoke it 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 description coverage is 100% — both trace_dir and trace_file have descriptions in the input schema. The description itself adds nothing about parameter formats, precedence, or relationships, so the baseline 3 applies.

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 ('correlate') and identifies its resources ('OpenTelemetry/Jaeger traces with static call graph'), plus the goal ('Find hot production paths and cold code'). It distinguishes itself from siblings like lilbrain_trace and lilbrain_hotspots by emphasizing the correlation between runtime traces and static structure, though it could be more explicit about how it differs from each sibling.

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 no explicit when-to-use, when-not-to-use, or alternative tools. It implies usage is for trace-to-callgraph correlation, but among 22 siblings—including lilbrain_trace, lilbrain_hotspots, and lilbrain_deadcode—an agent gets no routing guidance about choosing this tool over those.

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 only states the search scope and does not explain result format, matching behavior, whether it is read-only, pagination, or query syntax. 'Search' implies a read operation, but important behavioral details 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 one short, front-loaded sentence with no filler. Every word contributes to the tool's purpose and scope, and the content type list is efficiently packed into a colon-separated enumeration.

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 simple with one parameter and full schema coverage, which lowers the required descriptive burden. Still, there is no output schema and no explanation of what a search result looks like, nor guidance on choosing between this and specialized siblings. It is adequate for basic invocation but has clear 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 schema only describes the query parameter as 'Search query', which is minimal. The description adds meaning by clarifying that the query can target functions, classes, sections, and constants, giving the agent a better sense of what the query parameter should contain. Some query syntax or matching details are still absent, but the added context is valuable.

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 identifies a clear verb ('Search') and resource ('everything') and enumerates specific content types: functions, classes, sections, constants. This makes the tool's broad scope clear and distinguishes it from specialized siblings like lilbrain_function and lilbrain_file, though it does not explicitly name those 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 phrase 'Search everything' implies this is a general-purpose lookup tool for when the exact location or type is unknown. However, the description gives no explicit when-to-use or when-not-to-use guidance, and it does not mention that specialized sibling tools may be better when the target type is already known.

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 core behavior: approximate matching by meaning rather than exact name, with a concrete example showing how a query maps to multiple functions. It doesn't describe output format or matching limits, but the behavior is adequately conveyed for a search 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?

Two concise sentences, front-loaded with the core purpose, followed by a clarifying example. No wasted words or redundant restating of schema fields.

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 simple: two parameters, no nested objects, no annotations, no output schema. The description communicates what results look like ('finds functions') and gives a concrete example. It could mention output shape or result limitation, but overall it is sufficient for an agent to call this 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 100%, so the schema already documents both parameters and their descriptions. The description adds a useful example of how the query parameter is interpreted semantically, but does not need to explain 'n' since the schema covers it.

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 performs semantic search to find functions by meaning, which is a specific verb and resource. It also distinguishes itself from name-based search tools like lilbrain_search by explicitly saying 'not just by name.'

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 makes the intended usage clear: natural-language meaning-based queries for function lookup. The example strongly implies when this tool should be chosen over keyword/name search, though it does not explicitly name an alternative or state 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 behavioral disclosure burden. It does reveal that the tool returns files, top functions, and languages, which suggests a read-only introspection operation. However, it does not specify output format, what 'top functions' means, or confirm behavior beyond the vague 'deep dive' language.

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 a single, front-loaded sentence with no filler. It states the action, the resource, and the expected output categories compactly, making it easy for an agent to parse 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?

For a one-parameter tool, this is minimally viable, but there is no output schema, so the return value is only vaguely described. It also fails to disambiguate against similar sibling tools, leaving the agent to guess when this tool is the right choice among 23 alternatives.

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 100%: the only parameter, 'name', is described as 'Subsystem name'. The tool description adds no extra meaning to that parameter beyond establishing the subsystem context, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb/resource pair ('Deep dive into a subsystem') and enumerates the main content categories returned: files, top functions, languages. It is clear about what the tool does, though it does not explicitly differentiate itself from sibling tools like lilbrain_overview or lilbrain_architecture.

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?

There is no guidance on when to use this tool versus the many siblings. 'Deep dive' implies detailed subsystem inspection, but there are no prerequisites, exclusions, or alternative routing, so an agent must infer when this tool is preferred over lilbrain_overview, lilbrain_file, or lilbrain_architecture.

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?

The phrase 'Depth-limited' discloses an important behavioral constraint, and 'trace' implies a read-only analysis operation. However, with no annotations, the description still leaves side effects, traversal direction, and output behavior to inference.

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 a single terse phrase with no filler, and the key constraint 'Depth-limited' is front-loaded. It earns its place, though it reads as a noun fragment rather than a complete action-oriented sentence.

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 simple parameters and no output schema, the description conveys the starting point and depth limitation adequately. It does not explain what the returned call chain looks like, how depth is counted, or how this trace differs from sibling tools, which would help an agent invoke it 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 already documents both parameters with 100% coverage ('Starting function' and 'Max depth'), so the description does not need to carry much parameter meaning. It adds only a lightweight mapping: 'from a function' to the name parameter and 'depth-limited' to the depth parameter, with no new format or interpretation details.

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 identifies a specific operation: a depth-limited call chain trace starting from a function, which goes beyond the bare tool name. It is not fully differentiated from siblings like lilbrain_callers or lilbrain_dataflow, but the core purpose is reasonably 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?

No guidance is given about when to use this tool versus alternatives such as lilbrain_callers, lilbrain_function, or lilbrain_dataflow. The description implies only that a starting function is needed, with no conditions, exclusions, or selection criteria.

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