Wit.ai

@wit.ai list all intents in my customer-support app and show me which ones have the fewest training examples

Based on the app's current configuration, here are the intents sorted by training example count: • cancel_subscription (3 examples) • update_payment (5 examples) • track_order (12 examples) • request_refund (18 examples) • general_inquiry (47 examples) The cancel_subscription and update_payment intents appear undertrained compared to others. Consider adding more varied phrasings to improve recognition accuracy for these critical user flows.

This example shows read-only intent analysis — useful for auditing NLU model health. Requires an API key with read access to the target app. The MCP retrieves intent metadata but doesn't evaluate training quality; the AI infers gaps from example counts.

@wit.ai create a new trait called 'urgency_level' with values low, medium, and high for my support bot

Created trait 'urgency_level' in your Wit.ai app with three values: • low • medium • high The trait is now available for annotation in your training data. Next steps: label existing utterances with urgency levels so the model learns to detect priority signals in user messages. You can assign traits to utterances through the Wit.ai console or via the training API.

This demonstrates write capability — the MCP modifies your Wit.ai app structure. The trait exists immediately but won't affect predictions until you annotate training examples. Requires API key with write permissions. Changes are permanent unless manually deleted.

@wit.ai compare the intent coverage in my production app versus my staging app and tell me what's missing in staging

Comparing intent definitions across environments: **Production-only intents (missing in staging):** • escalate_to_human • update_subscription_plan • request_data_export **Staging-only intents (not yet in production):** • beta_feature_inquiry Your staging environment is missing three production intents that handle account management and compliance workflows. Consider syncing these before your next deployment to avoid recognition gaps when users migrate to the new bot version.

This synthesis example chains multiple app detail fetches with AI reasoning to spot configuration drift. Useful for multi-environment NLU ops. The MCP retrieves app metadata separately; the AI performs the diff analysis. Both app IDs must be accessible with your API key.

Use Wit.ai MCP when your support bot needs a quarterly intent review

A 6-person support team runs a Wit.ai-powered chatbot fielding 200 tickets a day. Every quarter, they audit which intents are firing, which are dead weight, and whether new customer language patterns need new traits. The Wit.ai MCP is the right call here: you pull all intents and traits in one Switchy session, compare firing rates from your analytics tool, and delete or merge intents without opening the Wit.ai console. The MCP's 10 tools cover the full CRUD loop—create, read, update app metadata, manage intents and traits. If your bot is stable and you're only tweaking once a month, the web UI is faster. But if you're iterating on intent design weekly or syncing bot config across multiple apps, the MCP saves 15 minutes per session by keeping the audit in your workspace.

When Wit.ai MCP speeds up bulk app provisioning

A 3-person product team is launching a voice assistant in 8 languages. Each language needs its own Wit.ai app with identical intent and trait scaffolding. The Wit.ai MCP wins here because you script the setup: create 8 apps, clone the base intent set, and define traits programmatically in one Switchy conversation. The alternative—manually clicking through the Wit.ai UI 8 times—takes an afternoon and invites copy-paste errors. The MCP's create-app and create-trait tools let you template the structure and iterate on trait definitions without leaving your workspace. The threshold: if you're only launching one or two apps, the UI is fine. But if you're provisioning more than 3 apps or need to replicate a config across environments (dev, staging, prod), the MCP pays off immediately.

Use Wit.ai MCP when live intent metadata informs your debugging

A solo developer is debugging why a production chatbot misroutes 12% of customer queries. The issue is intent overlap—two intents fire for similar phrasing, and the wrong one wins. The Wit.ai MCP is the right tool because you need to inspect intent details, compare trait assignments, and test hypotheses in real time without context-switching to the Wit.ai dashboard. You fetch intent metadata, check which traits are attached, and cross-reference with your logs—all in one Switchy thread. The MCP's get-intent-details and list-traits tools surface the config that's live in production, so you're debugging the actual state, not a stale local copy. If your bot is simple (under 10 intents), the web UI is enough. But once you're managing 20+ intents with overlapping traits, the MCP keeps your debugging loop tight.