Skip to main content
Glama

Find existing answers

find_answers
Read-only

Searches forum history to find topics that already answer a question and extracts the accepted or strongest reply, labelling which was used.

Instructions

Find topics that already answer a question, and extract the answer from each. Prefers author-accepted answers when the Q&A plugin is installed, and falls back to the strongest reply otherwise — always labelling which it used, so an unconfirmed reply is never presented as a confirmed answer. This is the first tool to reach for when someone asks a question the forum may have seen before.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagsNoOnly topics carrying all of these tags.
depthNoHow many candidate topics to open and extract answers from. Default 5.
questionYesThe question, in natural language.
categoriesNoRestrict to these category ids.
solved_onlyNoOnly return topics with an accepted answer. Requires the Q&A plugin; ignored without it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnlyHint and openWorldHint, but the description adds substantial behavioral context: it prefers author-accepted answers when the Q&A plugin is installed, falls back to the strongest reply otherwise, and always labels which approach it used so unconfirmed replies are not presented as confirmed answers. This is exactly the kind of source-quality and fallback disclosure an agent needs beyond safety hints.

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?

Three sentences with zero waste, front-loading the core action and then adding the important fallback and routing context. Every sentence earns its place.

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?

The description covers purpose, preferred usage, fallback behavior, and plugin dependency well, and annotations cover safety. With no output schema, it could say more about the shape of the extracted answer or how results are structured, but it does signal that each answer is labelled by source, which is likely enough for correct invocation.

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

Parameters3/5

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

Schema description coverage is 100%, so all five parameters are already documented in the schema. The description does not add parameter-level meaning such as what depth controls or how category/tag filters combine, 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.

Purpose5/5

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

States a specific verb and resource ('Find topics that already answer a question, and extract the answer from each') and distinguishes itself from siblings by positioning as the first tool to reach for when a question may have been seen before. It also clarifies Q&A-plugin-dependent behavior, which helps differentiate it from generic search tools.

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

Usage Guidelines4/5

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

Explicitly says to reach for this first when someone asks a question the forum may have seen before, giving clear context for use. It does not name alternatives to avoid or state when-not-to-use conditions, so it stops short of a full routing guide.

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