This server is an AI-powered question-answering orchestrator for the Acme Robotics knowledge base, exposing a single ask tool that accepts natural language questions and returns synthesized answers.
Ask questions about Acme Robotics: Submit any natural language question via the ask tool to get a comprehensive, synthesized answer
Agentic reasoning loop: Powered by GPT-4.1, the agent plans tasks, tracks dependencies, and synthesizes final answers from gathered evidence
Question decomposition: Complex questions are automatically broken down into smaller, manageable sub-tasks
Semantic search: Queries an in-memory vector store of Acme Robotics documents using embedding-based cosine similarity retrieval
Parallel task execution: Independent sub-tasks are dispatched concurrently for efficient multi-point information gathering
Multi-hop retrieval: Supports questions requiring cross-referencing multiple documents or reasoning steps (e.g., sequential lookups, comparing market positions, cross-referencing strategy with funding data)
Deployment options: Can be deployed as a Claude.ai enterprise connector or tested locally via Claude Desktop with a proxy bridge
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@acme-mcp what is Acme's growth strategy and does their current funding support it?"
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.
A two-layer nested MCP (Model Context Protocol) system demonstrating MCP composition over HTTP/SSE — a server that is simultaneously a client to another MCP server.
Claude Desktop
│ stdio
▼
[stdio proxy] ← spawned by Claude Desktop, bridges stdio ↔ HTTP
│ HTTP/SSE (:8002)
▼
MCP 2: Orchestrator ← FastAPI/uvicorn, runs on the server
│ HTTP/SSE (:8001)
▼
MCP 1: Vector Store ← FastAPI/uvicorn, internal onlyMCP 1 (mcp1_vectorstore) is a low-level in-memory vector store. On startup it embeds 10 Acme Robotics documents via Azure OpenAI, then serves semantic search using numpy cosine similarity. It runs as a standalone HTTP service and is never exposed to Claude Desktop directly.
MCP 2 (mcp2_orchestrator) runs an agentic reasoning loop using GPT-4.1 via Azure AI Foundry. It exposes a single ask tool via HTTP/SSE, decomposes questions into tasks, retrieves against MCP 1 over HTTP, and synthesizes a final answer. Independent tasks are dispatched in parallel via asyncio.gather.
The proxy (extension/server/proxy.py) is a thin stdio↔HTTP bridge. Claude Desktop spawns it locally; it connects to MCP 2 over the network. This is the only piece that runs on client machines.
Related MCP server: Qdrant Neo4j Crawl4AI MCP Server
src/
├── mcp1_vectorstore/
│ ├── settings.py # endpoint, api_key, embedding deployment, port
│ └── server.py # FastAPI/SSE: search + list_documents tools
└── mcp2_orchestrator/
├── settings.py # endpoint, api_key, chat deployment, mcp1_url
├── mcp1_client.py # HTTP/SSE client wrapping MCP 1
├── agent.py # Agentic loop: scratchpad, task planning, parallel search
└── server.py # FastAPI/SSE: exposes the ask tool
extension/
├── manifest.json # Claude Desktop Extension manifest
└── server/
└── proxy.py # stdio ↔ HTTP/SSE bridge (runs on client machines)uv synccp .env.example .env
# Fill in Azure credentialsIn two separate terminals:
make run-mcp1 # vector store on http://0.0.0.0:8001
make run-mcp2 # orchestrator on http://0.0.0.0:8002Run make claude-config to print the config block, then paste it into %APPDATA%\Claude\claude_desktop_config.json and restart Claude Desktop.
This spawns proxy.py via WSL, which connects to MCP 2 over HTTP. Both servers must be running first.
For enterprise claude.ai, no proxy or client-side installation is needed:
Deploy MCP 2 on an internal server with a publicly reachable HTTPS URL
An org admin adds the URL once: claude.ai → Settings → Connectors → Add custom connector
Users click to enable it — no URL entry, no configuration
MCP 1 stays internal; only MCP 2 needs to be reachable from Anthropic's servers.
Any Claude Desktop user — not just local dev — needs the proxy to connect to an internal server, since Claude Desktop only speaks stdio. The .mcpb packages the proxy and all Python dependencies into a one-click install.
make pack # produces acme-orchestrator-proxy.mcpbBefore packing, update MCP2_URL in extension/manifest.json to point at your internal server (e.g. http://mcp.acme-internal.com:8002). Distribute the .mcpb to users — they double-click it in Windows Explorer and Claude Desktop installs it automatically.
Tool | Input | Output |
|
|
|
| — |
|
Tool | Input | Output |
|
| synthesized answer string |
The agent in agent.py maintains a per-request scratchpad:
{
"question": str,
"tasks": [{"id", "description", "status", "depends_on", "result"}],
"final_answer": str | None
}The LLM drives the loop using four internal tools: add_task, complete_task, search_knowledge, and finish. Tasks with satisfied dependencies are dispatched concurrently. The loop is hard-capped at 10 iterations.
These questions require multi-hop retrieval over the Acme Robotics knowledge base. The answers are not in any LLM's training data.
Sequential (two-hop):
"Who developed the navigation algorithm used in Acme's flagship product, and what is their academic background?"
Parallel + synthesis:
"Compare Acme's market position: how large is their biggest customer relationship, and how do they stack up against their main competitor?"
Multi-hop stretch:
"What is Acme's growth strategy, and does their current funding support it?"
Ask a question about Acme Robotics. The agent will decompose the question, retrieve relevant information from the knowledge base, and synthesize a final answer.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | The question to answer |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the process (decompose, retrieve, synthesize) but doesn't mention critical behavioral traits such as rate limits, authentication needs, error handling, or what happens if the knowledge base lacks information. For a tool with no annotations, this leaves significant gaps in understanding its operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, consisting of two clear sentences that directly state the tool's function and process. There's no wasted language, and every sentence contributes essential information, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (involving decomposition, retrieval, and synthesis) and the lack of annotations and output schema, the description is incomplete. It doesn't explain the return values, error conditions, or operational limits, which are crucial for an AI agent to use it effectively. The description covers the basic purpose but misses key contextual details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'question' parameter fully documented. The description adds no additional meaning beyond the schema, as it doesn't elaborate on parameter constraints, formats, or examples. With high schema coverage, the baseline is 3, and the description doesn't compensate with extra insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Ask a question about Acme Robotics' with the action 'decompose the question, retrieve relevant information from the knowledge base, and synthesize a final answer.' This specifies the verb (ask/decompose/retrieve/synthesize) and resource (Acme Robotics knowledge base). Since there are no sibling tools, differentiation isn't needed, making it clear but not requiring sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It states what the tool does but doesn't mention any prerequisites, constraints, or scenarios where it should or shouldn't be used. With no sibling tools, there's no explicit comparison, but it lacks any usage context beyond the basic function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0askWith only one tool, there is no possibility of ambiguity or overlap between tools. The single tool 'ask' has a clearly defined and distinct purpose, making it impossible for an agent to misselect between tools.
A single tool inherently has perfect naming consistency, as there are no other tools to compare it against. The tool name 'ask' follows a simple verb pattern, which is appropriate for its function.
One tool is generally too few for a server's purpose unless it is a trivial or highly specialized single-function server. For a domain like 'Acme Robotics', a single 'ask' tool feels thin and under-scoped, limiting the agent's ability to perform diverse operations.
Inferring the domain as 'Acme Robotics', the tool surface is severely incomplete. A single 'ask' tool provides no CRUD/lifecycle coverage, no ability to interact with robotics systems (e.g., control, monitor, configure), and leaves significant gaps that will cause agent failures in practical scenarios.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Stateless agentic tools over MCP: concept extraction, long-context, knowledge graph, planning.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Origin-Digital-LLC/nested-mcps'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
