Skip to main content
Glama
tosin2013

mcp-adr-analysis-server

by tosin2013
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

perform_research

Read-onlyIdempotent

Investigate any question by searching project files, prior tool usage, environment resources, and web fallback, then save a research document.

Instructions

Perform research using cascading sources: project files → session/tool-usage tracker → environment resources → web search (fallback)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
questionYesThe research question to answer
projectPathNoPath to project directory.
adrDirectoryNoDirectory containing ADR filesdocs/adrs
performWebSearchNoEnable web search recommendations when confidence is low
researchDirectoryNoDirectory the research document is written to. Previously unset and unsettable: output went to docs/context/research/ regardless (#1528).docs/research
confidenceThresholdNoMinimum confidence threshold (0-1) before suggesting web search

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.7.32
    • addedInput schema / properties / researchDirectory
      Added value: +{
+  "default": "docs/research",
+  "description": "Directory the research document is written to. Previously unset and unsettable: output went to docs/context/research/ regardless (#1528).",
+  "type": "string"
+}
  2. Addedv1.0.0

TDQS

A3.6/5.0
Behavior1/5

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

There is a direct contradiction between the annotation readOnlyHint: true and the parameter description for researchDirectory stating 'Directory the research document is written to.' This implies the tool writes a document, violating the read-only hint. The description fails to disclose or reconcile this side effect, and the annotation contradiction is severe.

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?

The description is a single, compact sentence that efficiently conveys the cascading source order and fallback. No unnecessary words or redundant details. It is well-structured and immediately understandable.

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 tool description provides sufficient context for an agent to understand its role in research tasks, especially with the cascade order. No output schema is present, but the description does not need to detail return format. However, the writing side effect is not mentioned in the overall behavior, leaving a gap in full contextual understanding.

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?

All 6 parameters are described in the schema with 100% coverage. Each parameter has a clear meaning: question, paths, boolean flag, and threshold. The descriptions are concise and adequate, though they do not add extra context beyond the schema. The 'researchDirectory' mention of writing is the only ambiguity, but it is tied to the parameter's purpose rather than its type.

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?

The description clearly states the tool's purpose: performing research using a cascading source order. The verb 'Perform research' is specific and the resource (multiple sources) is implied. It distinguishes itself from sibling research tools by highlighting the cascading approach and web fallback.

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?

The description implies usage for broad research across multiple sources, but does not explicitly state when to use this tool over alternatives like search_codebase or generate_research_questions. It lacks clear disambiguation or conditions for selection.

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

Deploy Server

Other Tools