Skip to main content
Glama

Process Multilingual Input

neuroverse_process
Idempotent

Process mixed-language inputs to detect language, extract intent, and perform safety checks. Supports Tamil, Hindi, Telugu, Kannada, and English code-switched text.

Instructions

Process mixed-language input through the full NeuroVerse pipeline.

Pipeline: Language Detect → Normalise → Intent Extract → Safety Check → (optional) Execute

Supported languages: Tamil, Hindi, Telugu, Kannada + English (code-switched).

Args:

  • text (string): Raw user input, possibly code-switched

  • user_id (string): User / agent identifier (default: "anonymous")

  • execute (boolean): Whether to also execute the intent (default: true)

Returns: JSON with keys: language, intent, safety, execution (if execute=true)

Examples:

  • "anna indha file ah csv convert pannu" → detects Tamil+English, extracts convert_format

  • "report banao sales ka" → detects Hindi+English, extracts generate_report

  • "drop database production" → BLOCKED by safety layer

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYesRaw user input (may be code-switched, e.g. Tamil+English)
user_idNoIdentifier for the user / agentanonymous
executeNoIf true, also execute the extracted intent after safety check

Implementation Reference

  • The handler implementation for the `neuroverse_process` tool, which orchestrates language detection, intent extraction, safety checks, and optional execution.
    server.registerTool(
      "neuroverse_process",
      {
        title: "Process Multilingual Input",
        description: `Process mixed-language input through the full NeuroVerse pipeline.
    
    Pipeline: Language Detect → Normalise → Intent Extract → Safety Check → (optional) Execute
    
    Supported languages: Tamil, Hindi, Telugu, Kannada + English (code-switched).
    
    Args:
      - text (string): Raw user input, possibly code-switched
      - user_id (string): User / agent identifier (default: "anonymous")
      - execute (boolean): Whether to also execute the intent (default: true)
    
    Returns:
      JSON with keys: language, intent, safety, execution (if execute=true)
    
    Examples:
      - "anna indha file ah csv convert pannu" → detects Tamil+English, extracts convert_format
      - "report banao sales ka" → detects Hindi+English, extracts generate_report
      - "drop database production" → BLOCKED by safety layer`,
        inputSchema: ProcessInputSchema,
        annotations: {
          readOnlyHint: false,
          destructiveHint: false,
          idempotentHint: true,
          openWorldHint: true,
        },
      },
      async (params) => {
        const lang = detectLanguage(params.text);
        const intent = await extractIntent(lang.normalizedText);
        const safety = await checkSafety(intent, params.text);
    
        const result: Record<string, unknown> = {
          language: lang,
          intent,
          safety,
        };
    
        if (params.execute) {
          const exec = await executeIntent(intent, safety);
          result["execution"] = exec;
        }
    
        return {
          content: [{ type: "text" as const, text: JSON.stringify(result, null, 2) }],
        };
      }
    );
  • Input validation schema (using Zod) for the `neuroverse_process` tool.
    const ProcessInputSchema = z
      .object({
        text: z
          .string()
          .min(1, "Text is required")
          .max(5000, "Text must not exceed 5000 characters")
          .describe("Raw user input (may be code-switched, e.g. Tamil+English)"),
        user_id: z
          .string()
          .default("anonymous")
          .describe("Identifier for the user / agent"),
        execute: z
          .boolean()
          .default(true)
          .describe("If true, also execute the extracted intent after safety check"),
      })
      .strict();
Behavior4/5

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

The description adds valuable behavioral context beyond annotations: it explains the multi-step pipeline, safety checking that can block requests, optional execution, and supported languages. While annotations provide hints (non-readOnly, openWorld, idempotent, non-destructive), the description adds practical implementation details about the processing flow and safety mechanisms.

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

Conciseness5/5

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

The description is well-structured and efficiently organized: purpose statement, pipeline overview, language support, parameter summary, return format, and illustrative examples. Every section adds value with zero wasted text, and information is front-loaded with the most important details first.

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

Completeness4/5

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

For a complex processing tool with no output schema, the description provides excellent context: it explains the multi-step pipeline, safety implications, return format, and includes concrete examples. The main gap is lack of explicit guidance on when to use sibling tools instead, but otherwise it's comprehensive for understanding the tool's behavior and outputs.

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

Parameters3/5

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

With 100% schema description coverage, the schema already documents all three parameters well. The description adds minimal value beyond the schema - it mentions code-switched input for the text parameter and provides default values, but doesn't explain parameter interactions or provide additional semantic context. This meets the baseline for high schema coverage.

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's purpose: 'Process mixed-language input through the full NeuroVerse pipeline' with specific pipeline steps listed (Language Detect → Normalise → Intent Extract → Safety Check → Execute). It distinguishes itself from siblings by focusing on end-to-end processing rather than specific components like neuroverse_execute or neuroverse_transcribe.

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 provides clear context for when to use this tool: for processing mixed-language input through the full pipeline. It mentions optional execution and safety checking, but doesn't explicitly state when to use alternatives like neuroverse_execute (for execution only) or neuroverse_transcribe (for transcription only). The examples help illustrate appropriate use cases.

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

Install Server

Other Tools

Latest Blog Posts

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/joshua400/neuroverse'

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