Integrations & MCP tools

One orchestrator, replaceable model providers

NietzX treats the model as a planner and language interface. The desktop host owns credentials, permissions, tool execution, validation, and the persistent task record. Changing providers does not grant a model direct operating-system access.

Request lifecycle

Every autonomous task is a bounded loop. NietzX can continue across multiple model and tool turns, but the host—not the model—decides what is executable and when the task is complete.

1. Normalize the task

   Capture the goal, active workspace, device policy, selected provider, and allowed tool classes.

2. Assemble context

   Load only relevant conversation state, permitted resources, and persistent-memory matches.

3. Call the provider

   Translate the neutral request into the provider’s required headers, body, and tool schema.

4. Validate a tool request

   Check the tool name, JSON Schema arguments, path or URL scope, and whether user approval is required.

5. Execute through MCP

   Send the approved request to the corresponding local or remote MCP server and capture structured output.

6. Return evidence

   Feed the bounded result back to the provider, continue if necessary, then verify and report the outcome.

Third-party provider APIs

Each provider has its own authentication and payload format. NietzX presents one internal interface and translates it at the network edge. Keys remain in the operating system’s credential store and are never inserted into prompts, tool arguments, analytics, or support messages.

curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  --data-binary @- <<JSON
{
  "model": "$NIETZX_ANTHROPIC_MODEL",
  "max_tokens": 1024,
  "messages": [{"role":"user","content":"Summarize this task."}]
}
JSON

curl https://api.openai.com/v1/responses \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  --data-binary @- <<JSON
{
  "model": "$NIETZX_OPENAI_MODEL",
  "input": "Summarize this task."
}
JSON

curl https://api.deepseek.com/chat/completions \
  -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
  -H "Content-Type: application/json" \
  --data-binary @- <<JSON
{
  "model": "$NIETZX_DEEPSEEK_MODEL",
  "messages": [{"role":"user","content":"Summarize this task."}],
  "stream": false
}
JSON

curl "https://generativelanguage.googleapis.com/v1beta/models/${NIETZX_GEMINI_MODEL}:generateContent" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -X POST \
  -d '{"contents":[{"parts":[{"text":"Summarize this task."}]}]}'

Provider-neutral adapter contract

The orchestrator should never branch throughout the application on a provider name. One adapter boundary contains authentication, request translation, streaming events, usage accounting, and provider errors.

type ProviderRequest = {
  model: string;
  messages: NeutralMessage[];
  tools: NeutralTool[];
  signal?: AbortSignal;
};

type ProviderEvent =
  | { type: "text_delta"; text: string }
  | { type: "tool_call"; id: string; name: string; arguments: unknown }
  | { type: "usage"; inputTokens: number; outputTokens: number }
  | { type: "complete"; stopReason: string };

interface ProviderAdapter {
  stream(request: ProviderRequest): AsyncIterable<ProviderEvent>;
  validateModel(model: string): Promise<void>;
}

MCP architecture inside NietzX

Model Context Protocol is a JSON-RPC-based standard for connecting an AI host to tools, resources, and prompt templates. NietzX is the host; it creates an MCP client connection for each approved server.

{
  "name": "filesystem.read_text",
  "description": "Read UTF-8 text from an allowed workspace file.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "path": { "type": "string", "description": "Workspace-relative path" }
    },
    "required": ["path"],
    "additionalProperties": false
  }
}

NietzX MCP tool surface

These logical capability names document the public behavior expected from a NietzX build. Exact server and tool identifiers may vary by release, but the permission boundary must remain equivalent.

Security boundaries

Autonomy is useful only when authority is explicit. NietzX separates model selection, credential access, tool discovery, and tool execution so a compromised prompt cannot silently widen its permissions.

• Credential isolation

  Store provider secrets with Windows DPAPI or Apple Keychain. Resolve them only inside the provider adapter.

• Least-privilege tools

  Expose only the servers and tool classes required for the active task; start with read-only access.

• Argument validation

  Validate every tool payload against JSON Schema, canonicalize paths and URLs, and reject additional properties.

• Approval gates

  Require confirmation for destructive changes, external publication, purchases, messages, and new authority.

• Prompt-injection resistance

  Treat web pages and files as untrusted data. Their instructions cannot override host policy or user intent.

• Bounded logs

  Keep request IDs, timing, tool names, and errors; redact keys, private content, recovery phrases, and raw credentials.

• Remote MCP security

  Use TLS, authenticate the remote server, scope tokens, validate Origin where applicable, and do not expose local servers publicly.

• Result verification

  Check file existence, page state, response status, or other direct evidence before reporting that an action succeeded.

Llama 3.1 8B through Ollama

Local inference keeps prompts and model execution on the user’s device and removes per-token cloud-provider billing. The trade-off is local storage, memory pressure, and lower generation speed on CPU-only systems.

ollama run llama3.1:8b

curl http://localhost:11434/api/chat \
  -d '{
    "model": "llama3.1:8b",
    "messages": [{"role":"user","content":"Describe the active task."}],
    "stream": false
  }'

NietzX deployment guidance

Ollama publishes model size and supported hardware, but it does not publish one universal minimum-RAM number for this model. The following figures are operational guidance, not vendor guarantees; memory use grows with context length and concurrent workloads.

Errors, retries, and observability

A provider response or MCP result is evidence, not an unconditional success signal. The runtime preserves enough structured information to retry safely, diagnose failures, and avoid duplicate side effects.

Official sources

The protocol, endpoints, authentication headers, model artifacts, and hardware-support statements above were checked against primary documentation. Provider model availability should still be resolved at runtime.

• MCP architectureModel Context Protocol
• Claude API overviewAnthropic
• Models and Responses availabilityOpenAI
• First API callDeepSeek
• Gemini API referenceGoogle AI for Developers
• Llama 3.1 model libraryOllama
• Local chat APIOllama
• Hardware supportOllama