repowise

get_answer

Read-only

Answer a how, where, or why question about a codebase in one evidence-grounded call, returning citations and ranked candidate files to verify.

Instructions

Answer a how, where, or why question in one evidence-grounded call.

High confidence may be used directly; medium and low lead with the
evidence to verify. ``candidate_files`` ranks files worth opening that
the citations do not name.

Args:
    question: One question about one subject. Split "where is X and
        when does Y run" into two calls; do not paste a whole
        multi-part task.
    scope: repository-relative path prefix.
    repo: usually omitted.
    include: ``["evidence"]`` expanded evidence; ``["diagnostics"]``
        adds ``retrieval_quality``.

Input Schema

Name	Required	Description	Default
`repo`	No
`scope`	No
`include`	No
`question`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv0.60.1Nov 3, 2026
- removedInput schema / properties / include / default
```
Removed value: -null
```
- removedInput schema / properties / include / title
```
Removed value: -"Include"
```
- removedInput schema / properties / question / title
```
Removed value: -"Question"
```
- removedInput schema / properties / repo / default
```
Removed value: -null
```
- removedInput schema / properties / repo / title
```
Removed value: -"Repo"
```
- removedInput schema / properties / scope / default
```
Removed value: -null
```
- removedInput schema / properties / scope / title
```
Removed value: -"Scope"
```
- removedInput schema / title
```
Removed value: -"get_answerArguments"
```

Changed1 schema field changedv0.48.0Sep 3, 2026

addedInput schema / properties / include

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Include"
+}

Addedv0.39.0Aug 5, 2026
Removedv0.33.0Jul 18, 2026
First observedv0.1.0Jul 12, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Beyond the readOnly/openWorld annotations, the description discloses the confidence-tiering behavior and how medium/low results are presented (leading with evidence to verify), plus that `candidate_files` surfaces files the citations don't name. That is real behavioral context an agent could not infer from annotations alone; it stops short of describing failure modes or latency.

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

Conciseness5/5

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

Front-loaded with the action and the confidence contract in the first two lines, then a compact Args block. Every sentence carries operational information; there is no filler or restatement of the title.

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

Completeness4/5

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

An output schema exists, so return values need not be explained, and the description still adds the interpretive layer (confidence meaning, `candidate_files`, `retrieval_quality`) that the schema alone would not convey. The only real gap is the missing routing guidance among the many sibling retrieval tools.

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

Parameters4/5

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

Schema coverage is 0%, so the description must carry the burden, and it largely does: `question` is constrained to one question about one subject with an explicit anti-pattern, `scope` is defined as a repository-relative path prefix, `repo` is marked as usually omitted, and `include` gives concrete values with the effect of `diagnostics`. `repo` remains thin (no format guidance) and `include` gives examples rather than the full accepted set.

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

Purpose4/5

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

States a specific verb and resource — answering a how/where/why question in one evidence-grounded call — and clarifies the confidence contract. It does not differentiate itself from the sibling `get_why`, which by name appears to answer overlapping 'why' questions, leaving an ambiguity an agent must resolve on its own.

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

Usage Guidelines3/5

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

Gives useful in-call guidance: split multi-part questions into separate calls, don't paste whole tasks, and treat high confidence as usable vs. medium/low as needing evidence verification. However, it never says when to prefer this over `search_codebase`, `get_context`, or especially `get_why`, so tool selection among siblings is only implied.

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

Deploy Server