Priority — TypeScript Compiler Intelligence

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds that it returns direct and transitive dependency paths with source evidence and notes the x402 payment cost, which is useful beyond annotations. However, it omits critical behaviors like whether files must be complete or truncated, how symbol matching works, and rate limits or authentication details beyond payment.

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?

Three sentences, front-loaded with the core purpose, followed by return details and payment context. No 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 4 parameters with 0% schema coverage, no output schema, and complex behavior (impact analysis), the description is incomplete. It omits parameter explanations, response format details beyond paths, and operational constraints like file limits or symbol matching rules.

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

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

Schema description coverage is 0%, so the description must compensate but provides no information about the four parameters (files, limit, offset, symbol). It does not explain that files require paths and content, what symbol refers to, or how pagination works.

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 specific verb ('Determine') and resource ('what code may be affected by changing a TypeScript or JavaScript symbol'), clearly distinguishing it from siblings like find_references or get_importers. The mention of direct and transitive dependency paths further pins down the scope.

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

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

Implies usage via 'changing a symbol' but offers no explicit when-to-use, when-not-to-use, or comparison to alternatives like find_references. An agent must infer the context without 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuinely new behavioral context not in the annotations: compiler-backed semantic resolution and commercial terms ('Paid via x402 (starting $0.02)'). It omits auth/payment mechanics and any failure behavior when symbol resolution succeeds or fails.

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?

Three short sentences, purpose front-loaded, capability and cost appended in descending priority. No filler, no repetition 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?

With 0% parameter coverage, no output schema, and no explanation of the return shape, ordering, or pagination, an agent cannot confidently form a call beyond passing a file array. Annotations cover safety, and pricing is disclosed, but the absence of any parameter or result semantics for a four-parameter tool leaves a significant 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?

Schema description coverage is 0% across four parameters, so the schema alone gives no meaning for files, symbol, limit, or offset. The description mentions a 'symbol' and 'supplied files' in passing but never clarifies that symbol is the lookup target, how it is qualified, or what limit/offset paginate — and it does not flag that only 'files' is marked required despite symbol being conceptually essential.

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 specific verb (find) and resource (semantic references to a TS/JS symbol) plus the mechanism (compiler-backed symbol identity), which meaningfully separates it from textual search. However, it never names or contrasts with the available siblings (analyze_impact, get_importers, get_imports, query_code), so the differentiation is inferential rather than explicit.

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?

Usage is implied: 'Handles renamed imports and re-exports' tells the agent this tool is preferable when name-based matching would fail, and 'across supplied files' hints at the input scope. There is no explicit when-to-use/when-not guidance and no routing to alternatives like query_code or get_importers.

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 already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds cost behavior not present in structured data ('Free') and flags that billing/pricing status is part of the output, which is genuinely additive context for an agent deciding whether to call it.

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 compact sentences with no filler, front-loading the returned content and closing with the call-ordering instruction. Every clause carries distinct information.

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 discovery tool with no output schema, the description carries the burden of telling the agent what comes back, and it does so by enumerating the content categories. It does not describe the response shape (e.g., the fields around the pricing or billing status), leaving a small gap, but nothing needed to invoke it correctly 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 tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The listed content topics serve as an informal description of what the parameterless call returns.

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 specific verb ('Get') and resource ('capabilities') and then enumerates the exact content returned: languages, free vs paid operations, input limits, privacy posture, x402 pricing and billing status. This is immediately distinguishable from the sibling code-analysis tools (query_code, find_references, etc.), which deal with source artifacts rather than server metadata.

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?

Gives explicit ordering guidance: 'Call first when discovering this server.' This tells the agent exactly when in the workflow to reach for it. It stops short of naming exclusions, but no sibling overlaps this tool's domain, so the omission is minor.

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 already declare readOnly, idempotent, non-destructive, closed-world, so safety is covered. The description adds genuinely non-structured context: the tool is paid via x402 starting at $0.02, and returns resolved module edges plus evidence, which tells the agent about cost and output character.

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 tight sentences with the core capability front-loaded and the cost caveat second. Every clause carries information; nothing is redundant.

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?

No output schema exists, and the description only hints at the return shape via 'resolved module edges and evidence'. With four parameters at 0% schema coverage, including an undocumented required nested array, the definition is not sufficient for an agent to construct a correct call.

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 never mentions files, limit, offset, or symbol. Critically, the required parameter is a batch array of {path, content} objects (max 96), and nothing in the description signals that the agent must upload file contents rather than a path or module 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 specific verb and resource: find modules/files that import a target TS/JS module, i.e. reverse-dependency lookup. This implicitly disambiguates from the sibling get_imports (forward direction) and find_references, though it never names a sibling explicitly.

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 choose this over analyze_impact, find_references, or get_imports, and no stated prerequisites or exclusions. The only usable signal is the implied reverse-dependency framing.

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 annotations already establish that the tool is read-only, idempotent, non-destructive, and closed-world. The description adds valuable behavioral context by disclosing that it is paid via x402, with a starting cost of $0.02, and by indicating the kinds of resolved output returned. It does not describe pagination behavior, but the cost disclosure is meaningful beyond the annotations.

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, front-loaded with the core purpose and followed by essential payment information. There is no filler or repetition, and every sentence adds value.

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

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

The description covers the tool's purpose, output categories, and cost, which is useful since there is no output schema. However, it omits parameter behavior, pagination, multi-file handling, and filtering semantics, leaving significant gaps for a tool with four undocumented parameters.

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 four parameters. It never explains the required files array, its path/content structure, the limit/offset pagination controls, or the symbol filter. The description fails to compensate for the complete lack of parameter documentation in 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 gives a specific verb and resource: 'Resolve' a TypeScript or JavaScript file's imports. It also names the resolved outputs (modules, bindings, aliases, source locations). It does not explicitly differentiate itself from the sibling get_importers, but the phrase 'file's imports' implies the inverse direction.

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 guidance on when to use this tool versus alternatives such as get_importers, find_references, or query_code. Usage is only implied by the tool name and description.

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 already cover read-only, idempotent, non-destructive semantics, so the bar is lower. The description adds genuinely new behavioral context: the pricing model and which queries incur charges, which materially affects invocation decisions. It stops short of describing pagination behavior despite limit/offset parameters existing.

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?

Three dense sentences, front-loaded with the purpose, then cost, then routing. No filler; every sentence changes how an agent would call the 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?

No output schema and 0% parameter description coverage leave return shape and several parameters undocumented. The description covers cost and routing well but omits pagination, the required symbol parameter, and input constraints (file count/size limits).

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

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

Schema description coverage is 0%, so the description must carry the burden. It explains the query parameter's free/paid split, which is real added meaning beyond the bare enum, but says nothing about files, symbol, limit, or offset.

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 concrete verb+resource ('compiler query over supplied JS/TS files') and enumerates the operation set (symbols, callers, callees, function, impact, references, imports, importers). It also positions itself against siblings by declaring it is the generic option and that specialized tools are preferred when intent is 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?

Gives explicit routing guidance: use this generically, prefer specialized tools when intent is clear, and it is not a repository index. It further splits usage by cost tier, naming exactly which query values are free and which are paid via x402 starting at $0.02.

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