Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
LAYA_MCP_MODELNoHugging Face model ID or local directory for the Core ML model.aac6fef/laya-multilingual-coreml-ane
LAYA_MCP_REVISIONNoOptional model revision.
LAYA_MCP_LOG_LEVELNoStructured stderr log level.INFO
LAYA_MCP_COMPUTE_UNITSNoCompute units: 'all', 'cpu', 'cpu_gpu', or 'cpu_ne'.model default
LAYA_MCP_LOCAL_FILES_ONLYNoSet to 'true' to disable model downloads and lookups, requiring a cached or local model.false

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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
infoA

Report server, resident backend, model, platform, limits, and metrics.

decideA

Make one bounded decision using the resident local model.

Decision kinds are binary, choice, and ordered_score. The server only signals needs_escalation; the caller remains responsible for any escalation.

batch_decideA

Make ordered bounded decisions in one MCP request.

Supply shared_context and omit item contexts, or omit shared_context and give every item its own context. This is API batching, not parallel inference.

filterB

Conservatively retain relevant, uncertain, failed, and oversized candidates.

Only a sufficiently confident irrelevant result excludes a candidate. The default response returns selected candidate text and aggregate metrics; use detailed for per-candidate diagnostics.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 4 tools

Disambiguation4/5

decide and batch_decide are clearly the single-item and batch variants of the same operation, while filter is a distinct conservative retention workflow. An agent might briefly hesitate between filter and repeated decide calls for relevance tasks, but the descriptions make each tool's purpose specific enough to avoid serious ambiguity.

Naming Consistency4/5

Most names are short, lowercase, action-oriented commands: info, decide, filter. batch_decide is the main deviation because it introduces an underscore and a compound form, but the naming remains readable and the relationship to decide is obvious.

Tool Count5/5

Four tools is well-scoped for this server's purpose: server introspection, single decisions, batched decisions, and candidate filtering. Each tool covers a distinct core workflow without redundancy or unnecessary surface area.

Completeness5/5

The tool surface covers the full apparent workflow: checking server state and limits, making a single bounded decision, making batched decisions, and conservatively filtering candidates. Escalation is intentionally left to the caller, so there are no obvious dead ends or missing operations.

Maintenance

ActivityMaintained
ResponsivenessNo issues