Skip to main content
Glama

Algenta MCP Server

by io.github.thyn-ai
OverviewDiscussionsAdmin

responses

Read-only

Run the unified Algenta utility response surface: deterministic tokenization/embeddings, or (for provider-backed chat models) a chat response with optional function/tool calling. input accepts a plain string, a list of independent strings (each processed as its own single-turn request), or a typed OpenResponses-style input array (items shaped {type: message|function_call|function_call_output, ...}) processed as ONE multi-turn conversation. previous_response_id continues a prior typed-array conversation -- state is held in the Algenta server process's memory only, so it does not survive a process restart or a different worker/replica.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
inputYesOne string, a list of independent strings (each its own single-turn request), or a typed OpenResponses-style input array processed as one multi-turn conversation.
modelNoModel id from list_models; selects the output item type.text.tokenizer
toolsNoFunction tools the model may call during this response, in OpenResponses function-tool shape.
dimensionsNoEmbedding vector length when the selected model produces embeddings.
tool_choiceNoControls whether the model calls a tool: auto, none, required, or a specific named function.
parallel_tool_callsNoWhether the model may emit multiple tool calls in parallel.
previous_response_idNoContinues a prior typed-array conversation; state lives in the server process's memory only.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • addedInput schema / properties / dimensions / description
      Added value: +"Embedding vector length when the selected model produces embeddings."
    • addedInput schema / properties / input / description
      Added value: +"One string, a list of independent strings (each its own single-turn request), or a typed OpenResponses-style input array processed as one multi-turn conversation."
    • addedInput schema / properties / model / description
      Added value: +"Model id from list_models; selects the output item type."
    • addedInput schema / properties / parallel_tool_calls / description
      Added value: +"Whether the model may emit multiple tool calls in parallel."
    • addedInput schema / properties / previous_response_id / description
      Added value: +"Continues a prior typed-array conversation; state lives in the server process's memory only."
    • addedInput schema / properties / tool_choice / description
      Added value: +"Controls whether the model calls a tool: auto, none, required, or a specific named function."
    • addedInput schema / properties / tools / description
      Added value: +"Function tools the model may call during this response, in OpenResponses function-tool shape."
  2. Changed5 schema fields changed
    • changedInput schema / properties / input / oneOf
      Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "items": {
-      "type": "string"
-    },
-    "type": "array"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "items": {
+      "properties": {
+        "type": {
+          "enum": [
+            "message",
+            "function_call",
+            "function_call_output"
+          ],
+          "type": "string"
+        }
+      },
+      "required": [
+        "type"
+      ],
+      "type": "object"
+    },
+    "type": "array"
+  }
+]
    • addedInput schema / properties / parallel_tool_calls
      Added value: +{
+  "type": "boolean"
+}
    • addedInput schema / properties / previous_response_id
      Added value: +{
+  "type": "string"
+}
    • addedInput schema / properties / tool_choice
      Added value: +{
+  "oneOf": [
+    {
+      "enum": [
+        "auto",
+        "none",
+        "required"
+      ],
+      "type": "string"
+    },
+    {
+      "properties": {
+        "function": {
+          "properties": {
+            "name": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "name"
+          ],
+          "type": "object"
+        },
+        "type": {
+          "enum": [
+            "function"
+          ],
+          "type": "string"
+        }
+      },
+      "required": [
+        "type",
+        "function"
+      ],
+      "type": "object"
+    }
+  ]
+}
    • addedInput schema / properties / tools
      Added value: +{
+  "items": {
+    "properties": {
+      "function": {
+        "properties": {
+          "description": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "parameters": {
+            "type": "object"
+          }
+        },
+        "required": [
+          "name"
+        ],
+        "type": "object"
+      },
+      "type": {
+        "enum": [
+          "function"
+        ],
+        "type": "string"
+      }
+    },
+    "required": [
+      "type",
+      "function"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
  3. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations declare readOnlyHint=true, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds important behavioral context: state for previous_response_id is held in server process memory only and does not survive restarts or different workers/replicas. It also clarifies that a list of strings is processed as independent single-turn requests, while a typed array is one multi-turn conversation. This goes beyond the annotations and helps the agent understand side effects and statefulness.

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 dense but well-structured, front-loading the core purpose and then explaining input modes and state behavior. Every sentence adds value, though it is somewhat long and could be tightened. The structure is logical: purpose, input modes, state caveat.

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?

Given the tool's complexity (7 params, 3 input modes, no output schema), the description covers the key behavioral aspects: input modes, statefulness, and model selection. It does not describe return values, but with no output schema, that is a minor gap. The description is complete enough for an agent to call the tool correctly in most cases.

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

Parameters4/5

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds meaning by explaining the three input modes and the stateful nature of previous_response_id, which is not fully captured in the schema. It also clarifies that model selects the output item type, which is useful. Baseline 3 is exceeded because the description adds semantic context beyond the schema.

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: run the unified Algenta utility response surface, covering deterministic tokenization/embeddings and provider-backed chat responses with optional function/tool calling. It distinguishes itself from siblings like tokenize, embeddings, and chat_completions by describing the unified surface and the three input modes.

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 explains when to use this tool: for deterministic tokenization/embeddings or provider-backed chat with tool calling, and it contrasts with the typed-array multi-turn conversation mode. It does not explicitly name sibling alternatives like tokenize or embeddings, but the context makes the usage clear. It lacks explicit when-not-to-use guidance, but the description is strong enough to guide selection.

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

All Algenta MCP Server toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources