DEMOGOD
How "Pseudo-Vision" via MCP Teaches Voice AI a Critical Lesson About Capability Gaps
# How "Pseudo-Vision" via MCP Teaches Voice AI a Critical Lesson About Capability Gaps
**Meta Description:** A hacker gave text-only GPT-OSS-120B vision using OpenCV + Google Lens via MCP. Voice AI demos have the same capability gaps. Here's why "pseudo-capabilities" are the solution.
---
## The Hack That Reveals the Pattern
A developer just shipped an MCP server that gives GPT-OSS-120B—a text-only model with zero vision support—the ability to "see" images.
Not by training. Not by fine-tuning. By **chaining tools**:
1. OpenCV detects objects in an image
2. Crops each object
3. Sends crops to Google Lens for identification
4. Returns results to the text-only model
GPT-OSS-120B, which has never seen a pixel, correctly identified an NVIDIA DGX Spark and a SanDisk USB drive from a desk photo.
**This isn't vision. This is "pseudo-vision"—and it works.**
The repo is called `noapi-google-search-mcp`. 17 tools total. No API keys required. Built on Playwright for scraping Google services. Two commands to install.
And it just taught Voice AI demos the most important architectural lesson of 2026: **You don't need native capabilities. You need composable tool chains.**
## Why This Matters for Voice AI Demos (The Capability Gap Problem)
Voice AI demos face the exact same problem GPT-OSS-120B faced: **capability gaps between what users need and what the model natively supports.**
### Voice AI Demo Capability Gaps:
**Gap 1: Visual Demonstration**
- User asks: "Show me the analytics dashboard"
- Voice AI can describe it, but can't render it
- **Native capability:** Text/voice only
- **Needed capability:** UI rendering
**Gap 2: Real-time Data Access**
- User asks: "What's my conversion rate this week?"
- Voice AI doesn't have access to user's live analytics data
- **Native capability:** Static training data
- **Needed capability:** Dynamic data fetching
**Gap 3: Multi-step Actions**
- User asks: "Create a test import with my sample CSV"
- Voice AI can't execute file operations or API calls
- **Native capability:** Text generation
- **Needed capability:** Action execution
**Gap 4: Domain-Specific Knowledge**
- User asks: "Does this integrate with our Salesforce custom objects?"
- Voice AI doesn't know user's specific Salesforce setup
- **Native capability:** General product knowledge
- **Needed capability:** User-specific context
These gaps are identical to GPT-OSS-120B's vision gap: **the model can reason, but lacks tools to access the required input/output modalities.**
## The "Pseudo-Vision" Solution Pattern
The `noapi-google-search-mcp` approach doesn't give GPT-OSS-120B actual vision. It gives it **a vision workaround via tool chaining**.
Here's the pattern:
```
┌─────────────────┐
│ Text-Only Model │
│ (GPT-OSS-120B) │
└────────┬────────┘
│
├─> "I need to identify objects in this image"
│
┌────▼─────┐
│ MCP │
│ Server │
└────┬─────┘
│
├─> Tool 1: OpenCV (object detection)
├─> Tool 2: Image cropping
├─> Tool 3: Google Lens API (identification)
│
└─> Returns: "NVIDIA DGX Spark, SanDisk USB drive"
Model receives text description, reasons about it as if it "saw" the image.
```
**This is pseudo-vision:** Model doesn't see pixels. Model sees *descriptions produced by vision tools*.
**Why it works:** GPT-OSS-120B is excellent at reasoning about text descriptions. It doesn't need to process raw pixels—it just needs someone/something to convert pixels to text. MCP + tool chain does that.
## Applying "Pseudo-Capabilities" to Voice AI Demos
If pseudo-vision works for text-only models, **pseudo-capabilities work for Voice AI demos**.
### Pattern 1: Pseudo-Visual Demonstration (Solved by Tambo)
Yesterday's article covered Tambo—generative UI toolkit where agents render React components. That's pseudo-visual demonstration for Voice AI:
```
┌─────────────────┐
│ Voice AI Demo │
│ (text/voice) │
└────────┬────────┘
│
├─> "I need to show the analytics dashboard"
│
┌────▼─────┐
│ Tambo │
│ MCP │
└────┬─────┘
│
├─> Tool 1: Select AnalyticsDashboard component
├─> Tool 2: Stream props {dateRange, metrics}
├─> Tool 3: Render component
│
└─> User sees dashboard while voice explains
Voice AI doesn't render UI natively. Tambo provides pseudo-visual capability.
```
### Pattern 2: Pseudo-Data Access (MCP Pattern)
Voice AI doesn't natively access user's live data. MCP tools provide pseudo-data access:
```
User: "What's my conversion rate this week?"
Voice AI: [Calls MCP tool: fetch_analytics]
MCP Tool Chain:
1. Authenticate with user's analytics platform
2. Query conversion rate (last 7 days)
3. Return structured data to Voice AI
Voice AI: "Your conversion rate this week is 4.2%, up from 3.8% last week."
```
Voice AI didn't "know" the answer. It knew *how to get the answer via tools*.
### Pattern 3: Pseudo-Action Execution (Tool Orchestration)
Voice AI doesn't execute actions natively. MCP tool chains provide pseudo-action capability:
```
User: "Create a test import with my sample CSV"
Voice AI: [Orchestrates MCP tools]
Tool Chain:
1. read_file("sample.csv") → returns CSV content
2. validate_format(csv_content) → returns {valid: true, rows: 150}
3. create_import_job({file: csv_content, mode: "test"}) → returns {job_id: "abc123"}
4. Render ImportProgressComponent via Tambo → user sees progress
Voice AI: "I've created a test import with your 150-row CSV. You can see the progress here..."
```
Voice AI didn't execute the import. It orchestrated tools that execute imports.
### Pattern 4: Pseudo-Domain-Specific Knowledge (Context Augmentation)
Voice AI doesn't know user-specific configurations. MCP tools provide pseudo-domain knowledge:
```
User: "Does this integrate with our Salesforce custom objects?"
Voice AI: [Calls MCP tool: fetch_salesforce_schema]
Tool Chain:
1. Authenticate with user's Salesforce instance
2. Fetch custom object schema
3. Compare against product's integration capabilities
4. Return compatibility analysis
Voice AI: "Yes, we support 8 of your 10 custom objects. Your 'Deal_Stage__c' and 'Custom_Pricing__c' objects are fully supported..."
```
Voice AI didn't have Salesforce knowledge. It fetched it on-demand via tools.
## Why "Pseudo-Capabilities" Beat "Native Capabilities" for Demos
### Advantage 1: Faster Time to Market
**Native capability approach:** Train model with vision support, wait months for research/training/fine-tuning
**Pseudo-capability approach:** Build MCP tool chain in days/weeks using existing services
GPT-OSS-120B's pseudo-vision shipped in weeks. Native vision would take months/years.
Voice AI demos with pseudo-visual (Tambo) + pseudo-data (MCP tools) ship in 4-6 weeks. Native multi-modal Voice AI with data access would take... unclear if even possible.
### Advantage 2: Modularity and Replaceability
**Native capability:** Tightly coupled to model architecture. Can't swap implementations.
**Pseudo-capability:** Loosely coupled via MCP protocol. Swap tools without retraining model.
Example: `noapi-google-search-mcp` uses Google Lens for object identification. If Google Lens gets too expensive or rate-limited, swap for:
- Clarifai API
- AWS Rekognition
- Custom YOLO model
- Whatever works
Voice AI demos using MCP tools have same advantage. Data fetching tool breaks? Swap implementations. Rendering library changes? Update Tambo components. **Model stays unchanged.**
### Advantage 3: Cost Efficiency
**Native capability:** Every user query burns GPU/TPU for multi-modal processing.
**Pseudo-capability:** Offload heavy lifting to specialized tools. Model only reasons about results.
GPT-OSS-120B doesn't process pixels (expensive). It processes text descriptions of pixels (cheap).
Voice AI doesn't render UI (model can't). It calls Tambo which renders UI (specialized React library, optimized for UI).
**Cost scales with reasoning, not with every modality.**
### Advantage 4: Verifiability and Debugging
**Native capability:** Black box. Model hallucinates? Good luck debugging multi-modal fusion layers.
**Pseudo-capability:** White box tool chain. Each step is inspectable.
`noapi-google-search-mcp` pseudo-vision fails? You can debug:
- OpenCV detection (did it find objects?)
- Cropping (are crops clean?)
- Google Lens API (did it return results?)
- Model reasoning (did it interpret results correctly?)
Voice AI demo with MCP tools fails? You can debug:
- Tool call (did agent select correct tool?)
- Tool execution (did tool return expected data?)
- Rendering (did Tambo show correct component?)
- Voice explanation (did agent describe correctly?)
**Each failure mode is isolatable and fixable.**
## The MCP Pattern: How to Build Pseudo-Capabilities
`noapi-google-search-mcp` demonstrates the complete pattern for building pseudo-capabilities via MCP.
### Step 1: Identify Capability Gap
**Question:** What does the model need to do that it can't do natively?
**GPT-OSS-120B example:** Identify objects in images (vision gap)
**Voice AI demo examples:**
- Render UI (visual gap)
- Access live data (data access gap)
- Execute actions (action execution gap)
- Know user-specific config (context gap)
### Step 2: Decompose Into Tool Chain
**Question:** What sequence of specialized tools can produce the required capability?
**GPT-OSS-120B pseudo-vision chain:**
1. OpenCV detects objects
2. Crop each object
3. Google Lens identifies objects
4. Return text descriptions
**Voice AI pseudo-visual demonstration chain:**
1. Agent identifies feature to show
2. Tambo selects matching component
3. Tambo streams props to component
4. Component renders
5. Voice explains while component displays
### Step 3: Implement MCP Server
**Pattern:** Each tool becomes an MCP tool with schema, execution logic, and error handling.
**`noapi-google-search-mcp` implementation (simplified):**
```python
from mcp.server import MCPServer
server = MCPServer("noapi-google-search")
@server.tool()
async def google_lens_detect(image_path: str) -> dict:
"""
Detect and identify objects in an image using OpenCV + Google Lens.
Args:
image_path: Path to image file
Returns:
dict with detected objects and their identifications
"""
# Step 1: OpenCV object detection
objects = detect_objects_opencv(image_path)
# Step 2: Crop each object
crops = [crop_image(image_path, obj.bbox) for obj in objects]
# Step 3: Google Lens identification
results = []
for crop in crops:
identification = query_google_lens(crop)
results.append(identification)
return {"objects": results, "count": len(results)}
```
**Voice AI pseudo-data-access implementation (simplified):**
```python
from mcp.server import MCPServer
server = MCPServer("user-analytics")
@server.tool()
async def fetch_conversion_rate(user_id: str, days: int = 7) -> dict:
"""
Fetch user's conversion rate for specified time period.
Args:
user_id: User identifier
days: Number of days to query (default: 7)
Returns:
dict with conversion rate data
"""
# Step 1: Authenticate
session = authenticate_analytics_platform(user_id)
# Step 2: Query data
data = session.query_conversion_rate(days=days)
# Step 3: Calculate trend
previous_period = session.query_conversion_rate(days=days, offset=days)
trend = calculate_trend(data, previous_period)
return {
"conversion_rate": data.rate,
"period_days": days,
"trend": trend,
"previous_rate": previous_period.rate
}
```
### Step 4: Model Learns Tool Usage via Schema
**MCP advantage:** Model sees tool schema and learns when/how to use tools.
**GPT-OSS-120B sees:**
```
Tool: google_lens_detect
Description: Detect and identify objects in an image using OpenCV + Google Lens
Parameters:
- image_path (string): Path to image file
Returns: dict with detected objects and their identifications
```
Model learns: "When user asks about image content, call `google_lens_detect` with image path."
**Voice AI sees:**
```
Tool: fetch_conversion_rate
Description: Fetch user's conversion rate for specified time period
Parameters:
- user_id (string): User identifier
- days (int, default=7): Number of days to query
Returns: dict with conversion rate, trend, previous period comparison
```
Model learns: "When user asks about conversion rate, call `fetch_conversion_rate` with their user_id."
### Step 5: Chain Multiple Tools for Complex Capabilities
**Single tool = simple pseudo-capability**
**Tool chain = complex pseudo-capability**
**GPT-OSS-120B pseudo-vision is actually a 3-tool chain:**
1. `detect_objects_opencv` (computer vision)
2. `crop_image` (image manipulation)
3. `query_google_lens` (object identification)
Chained together, they produce pseudo-vision.
**Voice AI "complete product demo" is a 5+ tool chain:**
1. `fetch_user_context` (who is this user? what's their setup?)
2. `identify_relevant_features` (what features match their question?)
3. `fetch_live_data` (get their actual data for demo)
4. `render_component` (show visual representation via Tambo)
5. `generate_explanation` (voice describes what's shown)
Chained together, they produce a complete, contextualized, data-driven demo.
## Four Pseudo-Capabilities Voice AI Demos Need (And How to Build Them)
### Pseudo-Capability 1: Product Context Awareness
**Gap:** Voice AI doesn't know which features exist, how they work, or what's currently in beta vs production.
**MCP Solution:**
```python
@server.tool()
async def get_feature_status(feature_name: str) -> dict:
"""
Get current status and details of a product feature.
Returns availability, limitations, beta status, documentation links.
"""
feature_db = load_feature_database()
feature = feature_db.get(feature_name)
return {
"name": feature.name,
"status": feature.status, # "production", "beta", "deprecated"
"limitations": feature.limitations,
"documentation_url": feature.docs_url,
"related_features": feature.related
}
```
**Usage:** User asks "Does this integrate with Salesforce?" → Agent calls `get_feature_status("salesforce_integration")` → Returns current status → Agent gives accurate answer.
### Pseudo-Capability 2: User-Specific Configuration Knowledge
**Gap:** Voice AI doesn't know user's specific setup, integrations, or custom configurations.
**MCP Solution:**
```python
@server.tool()
async def get_user_integrations(user_id: str) -> dict:
"""
Fetch user's current integration connections and configurations.
Returns list of active integrations with their setup status.
"""
user = load_user_profile(user_id)
integrations = user.get_active_integrations()
return {
"integrations": [
{
"name": integration.name,
"status": integration.status,
"connected_at": integration.connected_at,
"sync_status": integration.last_sync
}
for integration in integrations
]
}
```
**Usage:** User asks "Show me my Salesforce data" → Agent calls `get_user_integrations(user_id)` → Checks if Salesforce connected → If yes, fetches data; if no, offers connection setup.
### Pseudo-Capability 3: Demonstration State Management
**Gap:** Voice AI doesn't track what's already been shown, what user understands, or where demo should go next.
**MCP Solution:**
```python
@server.tool()
async def log_demo_event(user_id: str, event_type: str, details: dict) -> None:
"""
Log demo events to track user's demo journey.
Enables smart "next step" suggestions based on what's been shown.
"""
demo_log = get_demo_log(user_id)
demo_log.append({
"timestamp": now(),
"event_type": event_type, # "feature_shown", "question_asked", "component_rendered"
"details": details
})
save_demo_log(user_id, demo_log)
@server.tool()
async def suggest_next_demo_step(user_id: str) -> dict:
"""
Analyze demo log and suggest next logical step.
Returns recommended feature to show based on user's journey.
"""
demo_log = get_demo_log(user_id)
user_interests = analyze_demo_log(demo_log)
# Find features user hasn't seen but are relevant to their interests
unseen_features = get_unseen_relevant_features(user_interests, demo_log)
return {
"suggested_feature": unseen_features[0] if unseen_features else None,
"reason": f"Based on your interest in {user_interests[0]}"
}
```
**Usage:** User finishes seeing Feature A → Agent calls `suggest_next_demo_step(user_id)` → Returns Feature B (related to A) → Agent: "Since you're interested in X, you might want to see Y..."
### Pseudo-Capability 4: Competitive Intelligence
**Gap:** Voice AI doesn't know how product compares to competitors or what differentiators matter for this specific user.
**MCP Solution:**
```python
@server.tool()
async def get_competitive_positioning(competitor_name: str, feature_category: str) -> dict:
"""
Get competitive positioning information for specific feature category.
Returns differentiation points and talking points.
"""
competitive_db = load_competitive_intelligence()
comparison = competitive_db.compare(our_product, competitor_name, feature_category)
return {
"our_advantage": comparison.advantages,
"their_advantage": comparison.disadvantages,
"talking_points": comparison.talking_points,
"evidence": comparison.proof_points # case studies, benchmarks, etc.
}
```
**Usage:** User mentions "We currently use Competitor X" → Agent calls `get_competitive_positioning("Competitor X", "integrations")` → Returns differentiation points → Agent: "Unlike Competitor X which only supports Y, we support Z..."
## The "Pseudo-Everything" Architecture for Voice AI Demos
Combining all pseudo-capabilities via MCP creates a complete Voice AI demo architecture:
```
┌─────────────────────────────────────┐
│ Voice AI Demo Agent │
│ (Core reasoning + conversation) │
└──────────────┬──────────────────────┘
│
│ MCP Protocol
│
┌────────▼────────┐
│ MCP Gateway │
└────────┬────────┘
│
┌──────────┼──────────┬──────────┬──────────┐
│ │ │ │ │
┌───▼───┐ ┌──▼──┐ ┌───▼───┐ ┌───▼───┐ ┌──▼──┐
│Tambo │ │Data │ │Context│ │State │ │Comp │
│Visual │ │Fetch│ │Aware │ │Mgmt │ │Intel│
└───────┘ └─────┘ └───────┘ └───────┘ └─────┘
Pseudo- Pseudo- Pseudo- Pseudo- Pseudo-
Visual Data Product Demo Competitive
Access Knowledge Tracking Intelligence
```
**Each MCP server provides pseudo-capabilities:**
- Tambo: Pseudo-visual demonstration (render React components)
- Data Fetch: Pseudo-data-access (live user data)
- Context Aware: Pseudo-product-knowledge (feature status, docs)
- State Mgmt: Pseudo-memory (demo journey tracking)
- Comp Intel: Pseudo-competitive-knowledge (positioning, differentiation)
**Voice AI orchestrates tool calls to create complete demo experience.**
## What `noapi-google-search-mcp` Teaches Us About Robustness
The project is called "noapi" for a reason: it uses Playwright to scrape Google services instead of official APIs.
**Why?** Because APIs have:
- Rate limits
- Costs
- Authentication complexity
- Service dependencies
**Scraping with Playwright:**
- No rate limits (use residential proxies if needed)
- No API costs
- No auth complexity (just log in like a human)
- Works as long as Google UI exists
**But here's the catch:** Comments on HN point out TOS violations, fragility, and Cloudflare blocks.
**This reveals a critical trade-off for pseudo-capabilities:**
### Approach 1: Official APIs (Robust but Constrained)
- **Pros:** TOS-compliant, stable schemas, support channels
- **Cons:** Rate limits, costs, vendor lock-in, feature restrictions
### Approach 2: Scraping/Workarounds (Flexible but Fragile)
- **Pros:** No limits, no costs, access to any visible data
- **Cons:** TOS violations, brittle (UI changes break it), CAPTCHA blocks
**Voice AI demos face the same trade-off:**
**Fetching user data via official API:**
- Requires user to connect integration
- Limited by API rate limits and capabilities
- Stable and reliable
**Fetching user data via scraping (like `noapi-google-search-mcp`):**
- Requires user's login credentials (sketchy)
- No rate limits
- Breaks when UI changes
**Lesson:** Choose API-first for production pseudo-capabilities. Use scraping only for prototyping or when no API exists.
## Why This Matters NOW (And Why It Didn't Matter Before)
**Before MCP:** Building tool integrations for AI agents meant custom protocols, complex orchestration, brittle connections.
**After MCP:** Standardized protocol means tools are plug-and-play. Any MCP-compatible agent can use any MCP server.
`noapi-google-search-mcp` works with:
- GPT-OSS-120B
- Claude (via MCP)
- Any other MCP-compatible model
**Voice AI demo tools built on MCP work across:**
- Different voice models (OpenAI TTS, ElevenLabs, custom)
- Different LLM backends (Claude, GPT-4, Llama)
- Different deployment contexts (web, kiosk, mobile)
**Pseudo-capabilities are portable across implementations.**
This is why pseudo-vision, pseudo-data-access, pseudo-visual-demonstration all ship NOW instead of waiting years for native multi-modal Voice AI that does everything.
## The One Thing `noapi-google-search-mcp` Gets Wrong (And How to Fix It)
The project violates Google's TOS by scraping. This creates legal/reliability risk.
**Better approach for production Voice AI demos:**
### Rule 1: API-First for Core Capabilities
Use official APIs for capabilities you depend on (data fetching, integrations, actions).
### Rule 2: Open-Source Alternatives for Vision/Rendering
Use open-source tools (OpenCV, Tambo) for capabilities where vendor lock-in is problematic.
### Rule 3: Scraping as Last Resort
Only scrape when:
- No API exists
- Feature is non-critical
- User explicitly consents
- You have fallback when scraping breaks
### Rule 4: Build Swap-able Tool Chains
Design MCP tool chains so individual tools can be swapped without rewriting orchestration logic.
Example: Vision tool chain
```python
# Flexible tool chain design
async def identify_objects_in_image(image_path: str, method: str = "google_lens"):
if method == "google_lens":
return await google_lens_tool(image_path)
elif method == "clarifai":
return await clarifai_tool(image_path)
elif method == "aws_rekognition":
return await aws_rekognition_tool(image_path)
else:
raise ValueError(f"Unknown method: {method}")
```
If Google Lens gets blocked, swap to Clarifai. Model doesn't know/care—it still gets object identification results.
## The Timeline: When Pseudo-Capabilities Become Standard
**Q1 2026 (now):** Early adopters build MCP tool chains for pseudo-capabilities. Projects like `noapi-google-search-mcp` demonstrate patterns.
**Q2 2026:** First Voice AI demo products ship with pseudo-visual (Tambo) + pseudo-data-access (MCP tools) architecture.
**Q3 2026:** MCP tool marketplace emerges. Pre-built MCP servers for common pseudo-capabilities (Salesforce data, Stripe analytics, user context, competitive intel).
**Q4 2026:** "Pseudo-capability architecture" becomes standard pattern. Voice AI demos without MCP tool chains are considered incomplete.
**2027:** Native multi-modal models still don't match pseudo-capability flexibility. Why? Because tool chains are swappable, verifiable, and cost-efficient.
**This timeline is fast because the technology exists:** MCP standardized the protocol. Tools like Tambo handle specific capabilities. Developers just need to chain them.
## What to Build Right Now
If you're building Voice AI demos (or adding Voice AI to existing products), here's your MCP pseudo-capability roadmap:
### Week 1: Audit Capability Gaps
**Task:** List every user request your Voice AI can't handle natively.
**Categories:**
- Visual demonstration needs
- Live data access needs
- Action execution needs
- User-specific context needs
- Domain knowledge needs
**Output:** Prioritized list of pseudo-capabilities to build.
### Week 2-3: Build Core MCP Servers
**Task:** Implement 3-5 high-priority pseudo-capabilities as MCP servers.
**Start with:**
1. Data fetching tool (user's live analytics, usage stats, etc.)
2. Product context tool (feature status, documentation, limitations)
3. Visual rendering tool (Tambo integration for UI components)
**Pattern:**
```python
from mcp.server import MCPServer
server = MCPServer("voice-ai-demo-tools")
@server.tool()
async def your_pseudo_capability(params) -> result:
# Implementation
pass
```
### Week 4: Integrate with Voice AI Agent
**Task:** Connect Voice AI agent to MCP servers. Test tool calling.
**Validation:**
- Agent correctly identifies when to call tools
- Tool results integrate into voice responses
- Error handling works (what happens if tool fails?)
### Week 5-6: Build Tool Chains for Complex Capabilities
**Task:** Chain multiple tools for sophisticated pseudo-capabilities.
**Example chain:** Complete contextualized demo
1. `fetch_user_context` → who is this user?
2. `get_relevant_features` → what features match their industry/role?
3. `fetch_user_data` → get their actual data
4. `render_dashboard` → show visual representation via Tambo
5. `generate_explanation` → voice describes customized to their context
### Week 7+: Expand Tool Library
**Task:** Add more pseudo-capabilities based on user feedback.
**Candidates:**
- Competitive intelligence tools
- Integration status checkers
- Demo state tracking
- Conversion optimization tools (A/B test which demo paths convert best)
**Target:** 15-20 MCP tools covering all major capability gaps.
## The Bottom Line
A hacker gave GPT-OSS-120B vision without training it on pixels. They built a tool chain.
Voice AI demos don't need native multi-modal models that do everything. They need **composable MCP tool chains that provide pseudo-capabilities.**
**Pseudo-visual demonstration:** Tambo renders UI while voice explains.
**Pseudo-data-access:** MCP tools fetch live user data.
**Pseudo-domain-knowledge:** MCP tools look up product features, competitive positioning, user config.
**Pseudo-action-execution:** MCP tools orchestrate API calls, file operations, integrations.
Each pseudo-capability is:
- **Faster to build** than native capability (weeks vs years)
- **Modular and swappable** (change implementations without retraining)
- **Cost-efficient** (offload to specialized tools, model only reasons)
- **Verifiable** (inspect each tool in chain, debug failures)
`noapi-google-search-mcp` proved the pattern works. 17 tools. No API keys. Text-only model gets "vision."
Voice AI demos need the same architecture. Not one model that does everything. **One model that orchestrates tools that do everything.**
---
**Pseudo-capabilities via MCP aren't a workaround—they're the architecture.** And the companies building MCP tool chains for Voice AI demos now won't be waiting for native multi-modal models that may never match the flexibility, cost-efficiency, and debuggability of composable tool chains.
The tools exist. The protocol is standardized. The only question is whether you're building pseudo-capability architectures before your competitors do—or explaining to users why your Voice AI demo can describe features but can't show them, can answer questions but can't access their data, can talk but can't act.
---
*Learn more:*
- [noapi-google-search-mcp on GitHub](https://github.com/VincentKaufmann/noapi-google-search-mcp)
- [Show HN Discussion](https://news.ycombinator.com/item?id=46971287)
- [Model Context Protocol (MCP) Documentation](https://modelcontextprotocol.io)
← Back to Blog