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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds only that results include spans, top span text, and callers/callees, but it does not explain the tool's behavior, aggregation logic, or response shape beyond that fragment.

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 very short but under-specified rather than concise. It is not front-loaded with a clear action, and its noun-phrase fragment leaves essential information unstated.

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, 0% parameter coverage, and only a readOnly annotation, the description is far too thin to support correct invocation. It does not explain what a "brief" contains, how question/path/store affect results, or when this tool should be chosen.

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%, and the description does not mention any of the three parameters (question, path, store). It therefore provides no meaning for the required question parameter or the optional path/store filters.

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 some returned content (spans, top span text, callers/callees) but uses a fragment rather than a clear verb and does not explain what the tool actually does. It does not distinguish its purpose from siblings like semlith_symbol or semlith_neighbors.

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 semlith_brief versus alternatives such as semlith_symbol, semlith_neighbors, or semlith_impact. The phrase "in one call" hints at aggregation but does not state when that is 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?

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds that `tree: true` produces a directory view with symbols, but it does not disclose return shape, recursion behavior, or how `path` and `store` affect results.

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 resource question and appends the `tree` behavior efficiently.

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 has three parameters with no schema descriptions and no output schema. The description covers only the `tree` flag, leaving the meaning of `path`, `store`, and the expected return values unclear.

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%, and the description only explains the `tree` parameter. The `path` and `store` parameters are undocumented in both the schema and the description, leaving significant ambiguity for a 3-parameter tool.

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 as folder contents and hints at a directory-tree view. It does not explicitly distinguish the tool from siblings like semlith_search or semlith_read, so it falls 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 only guidance is the note that `tree: true` gives a directory view with symbols. There is no explanation of when to use this tool versus semlith_search, semlith_read, or other siblings, and no exclusions or prerequisites.

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?

readOnlyHint=true is consistent with a pure analysis tool, and the description adds useful scope information (transitive traversal, Type::method narrowing syntax) beyond the annotation. It says nothing about which store/index is consulted, whether results include indirect dynamic dispatch, or how missing symbols behave.

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 clauses, front-loaded with the core question the tool answers, with no filler. It is arguably over-compressed to the point of being telegraphic, but nothing is wasted.

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 3-parameter tool with no output schema, the description does not say what the result looks like (list of call sites? edges? grouped by file?), how store/path change the search space, or what happens when the symbol is ambiguous. An agent would have to guess on several call-shaping details.

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

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

Schema description coverage is 0% for 3 parameters. The description only implicitly maps "X" to the required name argument and hints at the "Type::method" narrowing format; path and store are completely unexplained in both the schema and the 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 phrase "What breaks if X changes: every call site, transitively" names a concrete analysis (reverse-dependency / impact) and its scope (transitive call sites), which separates it from semlith_read and semlith_symbol. It never names a sibling explicitly, so differentiation is inferred from the word "breaks" rather than stated.

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 framing "What breaks if X changes" implies a pre-refactor / before-you-change-something usage context, which is real guidance. There is no explicit statement of when to use this over semlith_neighbors or semlith_symbol, and no exclusions or prerequisites.

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 readOnlyHint annotation already declares this is a safe read, so the description carries no safety burden. Beyond that the description discloses nothing useful: no traversal depth, no directionality handling, no behavior when the symbol is ambiguous or missing, and no indication of result size.

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, front-loaded with the core semantic relation and followed by the usage cue. No filler and nothing buried; brevity is appropriate here, though it tips into under-specification.

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, no annotation detail beyond readOnly, zero parameter documentation, and several graph-traversal siblings, this description does not supply enough for an agent to call correctly. The critical unknowns — what `path` and `store` mean and what the response contains — are unaddressed.

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% across three parameters, so the description must compensate and does not. 'X' loosely implies the required `name`, but `path` and `store` are entirely unexplained in both schema and description, leaving two-thirds of the input surface opaque.

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 recognizable resource relation — 'Who calls X, and what X calls' — which conveys a bidirectional call-graph neighborhood lookup. However, it never differentiates from the closely related sibling semlith_impact (also a graph traversal) or semlith_symbol, so an agent must guess which one to reach for.

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?

'Use for caller questions' gives one implied trigger, which is more than nothing. But there is no exclusions guidance, no mention of when to prefer semlith_impact (transitive impact) or semlith_symbol, and no prerequisites or scope limits.

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 readOnlyHint annotation already establishes that this is a safe read operation, and the description is consistent with that. However, it adds no behavioral context about return format, error handling, truncation, or what 'whole' means for a symbol, leaving gaps beyond the annotation.

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 wasted words. The compressed syntax is efficient, though the phrase 'or a symbol (Type::method) whole' is slightly awkward to parse.

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

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

There is no output schema and no explanation of what is returned, such as source text, numbered lines, or symbol bodies. For a tool with two parameters and zero schema coverage, the description should also clarify the store parameter and distinguish this read from semlith_symbol.

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 carries the full burden, and it does explain the accepted syntax for the required target parameter. It never mentions the optional store parameter or its meaning, leaving a significant undocumented input.

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 read operation with the specific target forms it accepts: path:start-end, path:line, and Type::method. It does not differentiate itself from sibling tools such as semlith_symbol, leaving ambiguity about when a symbol should be read here versus via the symbol-specific tool.

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?

It lists accepted target formats but gives no explicit guidance on when to use this tool instead of siblings like semlith_search, semlith_symbol, or semlith_files. The agent must infer usage from the input syntax alone.

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?

readOnlyHint=true already covers the safety profile, and the description adds genuine behavioral context: results are rank-ordered spans, and exact mode escalates from ranking to a full grep -E line match. It says nothing about result count behavior, latency, or what the excerpt/span actually contains, so the added context is real but thin.

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?

It is small and front-loads the purpose, which is good. The trailing clause is a dense fragment ('Also ext, lang, prefer (code|docs), format: excerpt') that is hard to parse and, worse, spends its budget on parameters the schema does not have.

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 six parameters, 50% schema coverage, and no output schema, the description should at least fix the result shape and clarify path/store/local. It gives the return shape (ranked file:line spans) but leaves path globs, store scoping, and local semantics entirely to the schema, and its phantom parameter list undermines completeness.

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

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

exact is well explained (grep -E, every matching line), which is real meaning beyond the bare boolean in the schema. But the tail 'Also ext, lang, prefer (code|docs), format: excerpt' names four parameters that do not exist in the input schema, actively inviting invalid arguments, while the actual params path, store, local, and k get no attention at 50% coverage.

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

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

The description gives a recognizable job: answering 'where is X / how does X work' queries with ranked file:line spans, which separates it from structural siblings like semlith_symbol or semlith_neighbors. The verb is implied rather than stated ('search' never appears), and no sibling is named explicitly, so differentiation relies on the agent inferring from 'ranked spans' vs. symbol/impact 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?

It implies the usage context ('Where is X / how does X work') and gives one real routing rule: exact: true when you want every matching line, grep -E style. There is no when-not guidance and no explicit alternative named among the seven siblings, so an agent must guess whether to reach for this or semlith_symbol.

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?

readOnlyHint=true covers the safety profile, so the bar is lower, but the description adds essentially nothing beyond it: no output shape, no granularity, no note on cost or freshness of the index data. The one clause provided is a vague pointer at the return value rather than context an agent couldn't guess.

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 short fragment with no padding, so nothing is wasted, but the brevity comes from under-specification rather than economy. It is front-loaded only in the sense that it's a sentence fragment.

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 carries the full burden of explaining what comes back, and "per store" plus "what is indexed" is far too thin to tell an agent the shape, units, or meaning of 'store'. For an introspection tool whose whole value is its return value, this is a real 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 takes zero parameters, so the baseline is 4; the description has no parameters to explain and correctly doesn't invent any. Nothing here misleads about inputs.

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 fragment "What is indexed, per store" hints at a stats/coverage report grouped by store, but there's no verb and no named resource, so it reads close to a restatement of the tool name 'stats'. It does not distinguish this from siblings like semlith_files or semlith_symbol, which also concern indexed content.

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 when-to-use guidance, no statement of alternatives, and no indication of what question this tool answers that the other semlith_* tools don't. The agent must infer everything from the name.

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?

Annotations declare readOnlyHint=true, so safety is covered, but the description adds little beyond it: no statement of what is returned when a symbol is missing, whether callers/callees are scoped to a workspace or store, or how the store/path interplay affects lookup. "A row each" hints at output shape but is unexplained.

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?

It is two short sentences with no padding, so length is fine, but the structure is telegraphic and the most important element (what is being located) is abbreviated to "X," which front-loads ambiguity rather than 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?

For a 4-parameter tool with zero schema coverage and no output schema, the description should carry nearly everything, yet it omits parameter meaning, return shape (beyond "a row each"), and behavior when a symbol is absent or ambiguous. An agent could not reliably call this without guessing at path/store semantics.

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% for all four parameters (name, path, names, store), so the description must compensate and largely fails. It clarifies that names takes up to 20 entries and that the pair is singular/plural, but says nothing about path vs store or how they scope the lookup, leaving the two most ambiguous parameters undocumented.

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

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

The phrase "Where X is defined, with callers and callees" does convey a specific capability (definition lookup plus call graph), but the tool name is opaque (semlith_symbol) and the description never states the resource plainly (symbol/function definition). It is distinguishable from semlith_search or semlith_read only by inference, so it sits at vague-but-inferable rather than 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?

There is no explicit when-to-use guidance and no mention of alternatives, despite siblings like semlith_neighbors and semlith_impact that plausibly overlap with caller/callee information. The only usage hint is buried in the fragment "names: up to 20, a row each," which tells batch size, not selection criteria.

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