Adaptive Tech Radar MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GITHUB_TOKEN | No | Optional GitHub token to increase GitHub API rate limits from 60 to 5,000 requests per hour. | |
| RADAR_STORAGE_DIR | No | Optional directory for local storage of the SQLite database and radar data, for example ~/.adaptive-radar. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| radar_check_updatesA | Fetch and score recent AI/LLMOps tech updates against developer preferences and cost metrics. Args: fetch_remote: If True, queries tracked GitHub releases and RSS feeds before scoring. limit: Maximum number of evaluated recommendations to return. |
| radar_prepare_context7_verificationB | Prepares structured parameters to verify the selected release via Context7 MCP. Args: release_id: The unique ID of the release to verify. Returns: Structured dictionary specifying library_id and target queries for Context7. |
| radar_record_feedbackA | Record developer's decision (ACCEPTED, REJECTED, OBSERVED) to train active learning memory. Args: release_id: The unique ID of the release (e.g. 'gh:pydantic/pydantic-ai:v2.65.0'). decision: One of 'ACCEPTED', 'REJECTED', 'OBSERVED'. reason: Why you approved or rejected it (e.g. 'We need structured outputs', 'Too complex, prefer standard SDK'). |
| radar_set_stack_profileB | Update user developer profile and architectural focus. Args: keywords: Domain keywords (max 30 items, e.g. ['python', 'asyncio', 'mcp']). preferred_tools: Target tools/libraries (max 30 items, e.g. ['pydantic', 'fastapi', 'litellm']). banned_patterns: Disliked or unsafe patterns (max 30 items, e.g. ['eval', 'unbounded loops']). |
| radar_ingest_customB | Manually ingest a changelog post, article, or release note into the radar database. Args: title: Title or headline of the update. body: Body text or description. source_url: Optional source link. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Each tool has a clearly distinct role in the workflow: profile setting, update fetching/scoring, Context7 verification prep, feedback recording, and manual ingestion. There is no overlap between tools, and the descriptions make the boundaries explicit. An agent can easily select the correct tool for each step.
All tools use a consistent 'radar_' prefix followed by a verb_noun or verb_noun_noun pattern (check_updates, record_feedback, set_stack_profile, etc.). The convention is predictable and readable throughout. No mixing of camelCase or inconsistent verb styles.
With five tools, the server is well-scoped for a tech radar workflow. Each tool earns its place, covering the essential actions without bloat. The count aligns with a focused recommendation and feedback loop.
The surface covers the core lifecycle: profile setup, update retrieval and scoring, external verification prep, feedback recording, and custom ingestion. Minor gaps exist, such as no explicit tool to view the current profile or inspect learned memory, but these are likely not critical for the main workflow. The set enables end-to-end operation with small workarounds.