TypeSafe MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TYPESAFE_MODEL | No | Model alias; legacy name supported | jev-latest |
| TYPESAFE_API_KEY | Yes | Required bearer credential | |
| TYPESAFE_BASE_URL | No | API base URL | https://api.typesafe.ai |
| TYPESAFE_MAX_RETRIES | No | Retries after the initial request | 2 |
| TYPESAFE_DEFAULT_MODEL | No | Official SDK-compatible model name | jev-latest |
| TYPESAFE_MAX_STATE_CHARS | No | Serialized state limit | 120000 |
| TYPESAFE_TIMEOUT_SECONDS | No | Per HTTP attempt timeout | 10 |
| TYPESAFE_MAX_REQUEST_BYTES | No | Whole request limit | 512000 |
| TYPESAFE_MAX_QUESTION_CHARS | No | Serialized question limit | 60000 |
| TYPESAFE_MAX_RESPONSE_BYTES | No | Provider response limit | 4194304 |
| TYPESAFE_RETRY_BACKOFF_SECONDS | No | Initial exponential backoff | 0.5 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| evaluateA | Evaluate state with TypeSafe Jev and return the raw typed answers. Use for bounded noul, choice, or score questions; never for prose, code generation, arithmetic, or dates. |
| classifyC | Choose one label from a closed set and return its probability distribution. |
| scoreB | Rate state on an ordered rubric and return the weighted score, probabilities, and confidence. |
| checkC | Estimate the probability that a bounded yes/no proposition is true. |
| verifyB | Check several claims against the supplied evidence in one request. Results are review signals, not proof of truth. |
| gateA | Evaluate bounded pass checks and turn their probabilities into pass/review/fail. This is not an authorization or security boundary; keep normal human and policy controls. |
| routeC | Choose the next action from a closed set. This suggests an action; it does not execute it. |
| reviewB | Evaluate a diff, plan, or test report against checks and return pass/review/fail signals. It never edits files. |
| healthA | Inspect local MCP configuration without making a network request. Set live=true only for an explicit paid provider check. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Several tools occupy overlapping evaluative territory: evaluate, classify, score, and check all return probabilities or typed answers for bounded questions, and gate/review both produce pass/review/fail signals. The descriptions help but do not make the boundaries crisp enough for reliable tool selection.
Tool names are almost uniformly single-word lowercase verbs (evaluate, classify, check, route, score, verify, gate, review), which is a consistent style. The noun 'health' is the one clear deviation from the verb pattern.
Nine tools is within a reasonable scope for a server, and each tool has a plausible purpose. The count feels slightly higher than necessary because some tools could likely be consolidated without losing functionality.
The set covers a broad range of bounded evaluative tasks: raw typed answers, classification, probability checks, scoring, routing, verification, gating, and review. The main weakness is that the relationships between the overlapping evaluative tools are not structurally explicit, but no obvious critical operation is missing for the stated domain.