What can you do with this server?

The ACR MCP Server is a local-first AI orchestration runtime that exposes memory, skill, web, and task execution tools. You can: * memory_search: Search ACR's local persistent memory store by keyword to retrieve stored information. * skill_search: Search the local skill registry by keyword to find available skills. * web_fetch: Fetch and extract text from an HTTP/HTTPS URL, with configurable character limit. * browser_fetch: Render a URL in a headless browser to extract visible text, including JavaScript-rendered content inaccessible to web_fetch. * github_search: Perform read-only searches over GitHub issues and pull requests. * run_task: Execute an objective via ACR's task engine, with optional quality tier to select a provider (e.g., Ollama or cloud) over the default mock.

Which integrations are available for this server?

Provides tools for searching GitHub repositories, issues, and code. Allows routing model inference requests to local Ollama models for real inference.

How do I use ACR MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ACR MCP Server search my memory for deployment notes" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

ACR MCP Server

by hbkdad

Overview Schema Related Servers Score Discussions

Python

Local

ACR: Adaptive Cognitive Runtime

PyPI License: MIT

acr-runtime.netlify.app

A local-first AI orchestration runtime that runs entirely on your own machine. Persistent memory, a skill system, task/agent orchestration, and multi-provider model routing, all on SQLite, with no cloud account, API key, or telemetry required to try it. Point it at your own local Ollama models when you want real inference, or keep it on the zero-config mock provider indefinitely; ACR never assumes you're online or paying for anything.

pip install acr-runtime
acr db upgrade && acr doctor
acr run "say hello"

Full specification: ACR_MASTER_SYSTEM_PROMPT.md. Current implementation state: docs/ARCHITECTURE.md, the single source of truth for what's actually built, so nothing here duplicates that status and drifts stale.

What's here

A Python CLI (acr) built around a real task engine, a hybrid-retrieval memory store, a skill registry with routing/validation/evolution, model and tool routing with safe-mode-aware permission checks, an agent planner/critic/topology system, an operational dashboard with a real-telemetry visualization, and an MCP server exposing ACR's memory, skill, web, and GitHub search tools to any MCP client, including project-scoped registration for both Claude Code and Codex CLI out of the box. See docs/ARCHITECTURE.md for the full breakdown of what's implemented, how, and why.

Related MCP server: WEATHGARDS

Quick start

Install from PyPI:

pip install acr-runtime   # or: uv tool install acr-runtime
acr db upgrade            # create the local SQLite schema, no repo checkout needed
acr doctor

Or from a source checkout (for development; see CONTRIBUTING.md):

uv sync                 # install deps + local package into .venv
cp .env.example .env    # local dev data dir (repo-local ./data, gitignored)
uv run alembic upgrade head
uv run acr doctor

acr run "say hello"          # create + execute a task end to end
acr dashboard serve          # operational dashboard: http://127.0.0.1:8765
acr mcp serve                # MCP server (stdio by default)

(prefix with uv run if working from a source checkout instead of a pip/uv tool install)

Using ACR from Claude Code or Codex CLI

This repo ships project-scoped MCP server registration for both Claude Code and Codex CLI, so opening it in either offers ACR's memory/skill/web/GitHub search tools and task execution as MCP tools directly. Claude Code prompts for approval the first time it opens the project; Codex CLI only loads project-scoped config for a project you've marked trusted (codex trust prompt, or trust_level = "trusted" under [projects."<path>"] in your own ~/.codex/config.toml); either way, cloning the repo can't silently launch anything without you consenting.

Development

See CONTRIBUTING.md for the full workflow. Short version:

uv run pytest            # tests
uv run ruff check .      # lint
uv run ruff format .     # format
uv run pyright           # type check

License, security, support

MIT licensed. See SECURITY.md to report a vulnerability privately. For bugs, questions, or feature requests, use GitHub Issues.

If ACR is useful to you, consider supporting its development: ko-fi.com/hbkcustomsinc.

Available Tools

6 tools

browser_fetchB

Render a URL in a real headless browser and return its visible text, including JS-rendered content web_fetch can't see.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes
`max_chars`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden. It mentions using a 'real headless browser' but does not disclose behavioral traits such as execution time, resource usage, error handling, or side effects. This leaves significant gaps in transparency.

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

Conciseness4/5

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

The description is a single sentence that is concise and front-loaded with the main action. It is efficient but could include a bit more detail without being verbose.

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

Completeness3/5

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

Given the complexity of a headless browser tool and the existence of an output schema, the description covers the key differentiator from siblings. However, it omits information about error conditions, limitations, and parameter details, leaving it insufficient for complete context.

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

Parameters1/5

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. It does not explain the purpose or constraints of the 'max_chars' parameter, and only indirectly references the 'url' parameter by mentioning it. No additional semantic value is added beyond the schema.

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 renders a URL in a headless browser and returns visible text, including JS-rendered content. It distinguishes itself from the sibling 'web_fetch' by noting that web_fetch cannot see JS-rendered content, so the purpose is specific and well-differentiated.

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?

The description implies usage for pages with JS-rendered content that web_fetch cannot access, providing clear context. However, it does not explicitly state when not to use it or mention alternatives beyond web_fetch, so slightly lacking in complete guidelines.

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

github_searchC

Search GitHub issues and pull requests (read-only).

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`query`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations, the description must bear the full burden of behavioral disclosure. It only states 'read-only', which is a positive trait, but omits important details such as authentication requirements, rate limits, output format, or pagination behavior. This is insufficient for a search tool.

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

Conciseness3/5

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

The description is a single short sentence, which is concise. However, conciseness is only beneficial when the core information is present. Here, it omits critical details, making it under-specified rather than efficiently packed.

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

Completeness2/5

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

Given the tool has 2 parameters (one required), an output schema, and no annotations, the description is incomplete. It fails to explain parameters, return values, or usage context. While the sibling list provides some domain context, the description itself leaves significant gaps for the agent.

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

Parameters2/5

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

Schema description coverage is 0%, meaning the description must explain parameters. It does not mention 'query' or 'limit' at all, nor their formats, defaults, or constraints. The schema provides basic structure, but the description adds no semantic value, leaving the agent to guess parameter usage.

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?

The description clearly states the verb 'Search' and the resource 'GitHub issues and pull requests', and adds 'read-only' for behavioral context. It is specific enough to distinguish from sibling tools like memory_search or web_fetch, but could be more precise about the scope (e.g., whether it includes comments or only issues/PRs).

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

Usage Guidelines2/5

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

The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or compare with siblings like memory_search or web_fetch. The agent must infer appropriateness from the name alone.

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

memory_searchC

Keyword search over ACR's local memory store.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`query`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, so the description must cover behavioral traits. It does not disclose case sensitivity, whether it searches all users or current session, or if it returns full entries or excerpts. Minimal transparency.

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

Conciseness4/5

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

The description is a single sentence with only 6 words, making it very concise. It is front-loaded with the key action. However, the extreme brevity sacrifices necessary detail.

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

Completeness2/5

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

Given the lack of annotations, missing parameter semantics, and no usage guidance, the description is incomplete for an agent to correctly select and invoke this tool. The presence of an output schema does not compensate for these gaps.

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

Parameters1/5

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

The input schema has two parameters (query, limit) with 0% schema description coverage, but the description adds no explanation of their meaning, syntax, or valid values. The description relies entirely on the schema, which lacks human-readable details.

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?

The description clearly states the tool performs keyword search over ACR's local memory store, distinguishing it from sibling tools like skill_search or web_fetch. The verb 'search' and resource are specific, though 'ACR' is not expanded.

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?

No explicit guidance on when to use this tool versus alternatives. The description implies it is for local memory search, which is a basic context, but lacks exclusion criteria or links to sibling tools.

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

run_taskB

Run an objective through ACR's task engine. Uses the zero-config mock provider unless min_quality_tier is raised (or Settings.default_min_quality_tier is configured) to prefer a configured Ollama/cloud provider instead.

ParametersJSON Schema

Name	Required	Description	Default
`objective`	Yes
`min_quality_tier`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided; the description mentions the mock provider behavior but fails to disclose potential side effects, authentication needs, rate limits, or what happens to data during execution.

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

Conciseness4/5

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

Two concise sentences with no unnecessary words. However, the structure could be improved by front-loading the purpose more explicitly.

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

Completeness2/5

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

Given the lack of annotations, incomplete parameter descriptions, and no explanation of return values despite an output schema, the description leaves significant gaps in understanding the tool's behavior.

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

Parameters2/5

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

Schema description coverage is 0%; the description only alludes to min_quality_tier without defining it or the 'objective' parameter. It does not add meaningful meaning beyond the schema's property names.

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?

Clearly states the verb ('Run') and the resource ('objective through ACR's task engine'). The tool's purpose is distinct from sibling tools (search, fetch), making selection unambiguous.

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?

Provides context on provider selection based on min_quality_tier or default configuration, but lacks explicit guidance on when to use this tool versus alternatives or when not to use it.

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

skill_searchB

Keyword search over ACR's local skill registry.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`query`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description bears full responsibility for behavioral disclosure. It only states 'keyword search,' omitting details like exact vs. fuzzy matching, result format, pagination behavior, or error handling. This is insufficient for a search tool.

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

Conciseness4/5

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

The description is a single sentence, highly concise with no filler. However, it could be structurally improved by front-loading more context or breaking into multiple points for clarity.

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

Completeness3/5

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

The tool has an output schema, reducing the need to explain return values. However, the description lacks usage context such as when to use this vs. memory_search or web_fetch, making it adequate but not complete.

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

Parameters2/5

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

Schema description coverage is 0%, meaning the description must compensate. It adds no insight beyond the parameter names: 'query' and 'limit.' No format, restrictions, or default behavior is described, so it fails to enrich the schema.

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 'Keyword search over ACR's local skill registry,' identifying the verb (search), resource (skill registry), and scope (ACR's local). This distinguishes it from sibling tools like web_fetch and memory_search, which have different domains.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of use cases, exclusions, or prerequisites, leaving the agent to infer context from the name alone.

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

web_fetchC

Fetch a URL over HTTP(S) and return its extracted text.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes
`max_chars`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.4/5.0

Behavior2/5

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

No annotations provided. Description only mentions 'extracted text' but lacks details on HTTP methods, redirects, timeouts, or truncation behavior. Default max_chars parameter not explained.

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

Conciseness3/5

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

Single sentence is concise but omits important details. Minimal structure adequate for a very simple tool, but missing parameter context.

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

Completeness2/5

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

Lacks context for alternatives (browser_fetch) and does not leverage output schema to describe return value. Insufficient for agent to use accurately.

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

Parameters1/5

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

Schema description coverage is 0% and description adds no information about parameters 'url' or 'max_chars'. Agent has no guidance on input semantics.

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?

Description clearly states verb 'Fetch' and resource 'URL' with outcome 'return its extracted text'. No differentiation from sibling 'browser_fetch'.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives like 'browser_fetch'. Missing context about prerequisites or use cases.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.1.0Jul 29, 2026
- First observedbrowser_fetch
- First observedgithub_search
- First observedmemory_search
- First observedrun_task
- First observedskill_search
- First observedweb_fetch

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0

Disambiguation5/5

Each tool targets a distinct domain: memory search, skill search, web fetching (two variants), GitHub search, and task execution. No overlaps exist.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., memory_search, web_fetch, run_task), with clear prefixes for related operations.

Tool Count5/5

Six tools provide a focused set covering search, fetch, and task execution without being excessive or minimal.

Completeness2/5

Significant gaps exist: memory and skill stores only support search (no create/update/delete), and run_task lacks status or result retrieval, limiting the workflow.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
Backtest360 A
com.backtest360
MCP server exposing the Backtest360 engine API as tools for AI agents.
Finance Research & Data
202
UnifAPIOAuth
com.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Open Data Search AI & Machine Learning
2
SMI Aware AssistantOAuth
com.smiaware.mcp
Remote MCP server exposing SMI Aware tools, resources, and skills over Streamable HTTP.
Social Media Search
1

Related MCP Servers

openclaw-tools-mcp
Browser Automation Web Scraping Agent Orchestration
haliphax-ai
A
license
B
quality
F
maintenance
Exposes OpenClaw tools (web search, page fetching, browser automation, PDF analysis, messaging, inter-agent communication, Canvas) as MCP tools for ACP agents.
Updated 5 months ago (2026-03-27 07:01 UTC)
7
-
WEATHGARDS
Virtualization OS Automation Monitoring
liambuild
F
license
Not graded
quality
D
maintenance
Exposes MCP tools that enable remote LLMs to query local Docker containers, OS processes, and system services in real time.
Updated 3 months ago (2026-06-04 21:45 UTC)
-
OpenClaw MCP Proxy
Agent Orchestration Autonomous Agents
wenyue
F
license
Not graded
quality
D
maintenance
Exposes app-registered tools as an MCP server for OpenClaw, forwarding actual tool execution back to the app over a WebSocket bridge.
Updated 5 months ago (2026-03-29 09:53 UTC)
-
vera_mcp_service
RAG Systems Search
BKSLab
F
license
Not graded
quality
B
maintenance
MCP Tools Server that bridges the Agent Service with data services, currently enabling knowledge base search via the kb_search tool.
Updated 8 days ago (2026-08-29 20:52 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hbkdad/arc'

If you have feedback or need assistance with the MCP directory API, please join our Discord server