Skip to main content
Glama
Platano78

Smart-AI-Bridge

by Platano78

ask

Send one prompt to an AI backend and retrieve the response. Choose 'auto' for smart routing by task complexity or specify a model to direct the query to a particular provider.

Instructions

Send one prompt to one AI backend and return the response. model:'auto' lets SAB's router pick the best backend by task complexity + current health; passing a specific model name forces that provider. Use this for direct LLM queries that don't fit a more specialized tool. For multi-backend consensus on the same prompt, use council. For agentic multi-step work with a defined role, use spawn_subagent. For LLM-driven file generation or editing, use generate_file / modify_file so the file content stays out of Claude's context window. Read-only: makes one HTTP call to the chosen backend. Returns: {success, model, requested_backend, actual_backend, prompt (truncated preview), response (the LLM output), backend_used, fallback_chain, response_time, cache_status, thinking_enabled, max_tokens, was_truncated, smart_routing_applied, routing, processing_time}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelYesAI backend to query: auto (smart routing selects optimal backend), local (autodiscover vLLM/llama.cpp/LM Studio), gemini (Gemini Enhanced, 32K tokens), nvidia_deepseek (NVIDIA DeepSeek with streaming + reasoning, 8K tokens), nvidia_glm (NVIDIA GLM-5.2 code specialist, 32K tokens), openai (OpenAI GPT-5.2, 128K context, premium reasoning), groq (Llama 3.3 70B, ultra-fast 500+ t/s). The friendly aliases `deepseek` and `glm` are also accepted (mapped to nvidia_deepseek / nvidia_glm), matching the other tools. `nvidia_qwen` and `qwen3` are legacy aliases still accepted for back-compat (the lane served Qwen3 Coder 480B until NVIDIA retired it on 2026-06-11) — they resolve to nvidia_glm.
promptYesYour question or prompt (Unity/complex generations automatically get high token limits)
thinkingNoEnable thinking mode for DeepSeek (shows reasoning)
max_tokensNoMaximum response length (auto-calculated if not specified: Unity=16K, Complex=8K, Simple=2K)
force_backendNoForce specific backend (bypasses smart routing) - use backend keys like "local", "gemini", "nvidia_deepseek", "nvidia_glm", "openai", "groq" (legacy "nvidia_qwen"/"qwen3" also accepted)
model_profileNoOnly for the local backend: request a specific model id from your local router (llama-swap/llama.cpp/LM Studio). Valid values are whatever your own router serves — query its /v1/models endpoint for the list; SAB does not ship a fixed set. The id is passed through as the requested model, so an id your router does not serve fails the call (HTTP 400 model not found) rather than falling back. SAB also tries to load the model first if it is not resident, but that pre-flight step only probes http://localhost:8081 — if your server listens on another port the load is skipped (the request still goes to your configured endpoint). Omit to use whichever model is already loaded.
enable_chunkingNoEnable automatic request chunking for extremely large generations (fallback if truncated)
Behavior5/5

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

With no annotations, the description carries the full burden. It states 'Read-only: makes one HTTP call to the chosen backend,' explains the smart-routing vs forced-provider behavior, and enumerates the return fields (including fallback_chain, cache_status, was_truncated). It even discloses edge-case behavior of the 'model_profile' parameter. This gives the agent a thorough behavioral model.

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

Conciseness4/5

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

The description is long but every sentence carries distinct value: purpose, routing, usage directives, read-only note, and return contract. It is front-loaded with the core meaning and only slightly verbose in the return field list. The detail is justified by the tool's complexity, so a 4 rather than 5.

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

Completeness5/5

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

Given no output schema, the description compensates fully by listing all return fields. It covers when to use, routing options, the read-only nature, and even edge cases. No important gaps for a direct-query tool with complex routing.

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?

Schema description coverage is 100%, and the schema's property descriptions are already unusually rich (model enum semantics, token limits, local model handling). The description adds only minor extra context around 'model:'auto'' and the routing concept. Baseline 3 for high schema coverage is appropriate.

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 opens with a specific verb ('Send') and the exact resource ('one prompt to one AI backend') plus the outcome ('return the response'). It explicitly contrasts with sibling tools (council, spawn_subagent, generate_file/modify_file), so the tool's scope is clearly distinct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit directive: 'Use this for direct LLM queries that don't fit a more specialized tool,' followed by concrete alternatives for common cases (council for multi-backend consensus, spawn_subagent for agentic multi-step, generate_file/modify_file for file edits). This is model usage guidance.

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/Platano78/Smart-AI-Bridge'

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