Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@zettaquant-vslm-mcp Filter these earnings call sentences to only ones about AI capex plans."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server that exposes ZettaQuant V-SLM to any MCP-aware LLM host.
Add three lines to your Claude Desktop / Cursor / Zed / Windsurf config and your model can filter noisy context (earnings-call transcripts, news articles, long reports, log lines) using ZettaQuant's topic-conditioned relevancy classifier — typically cutting token spend before the language model even sees the input.
One tool, over stdio, via the Model Context Protocol:
Tool | Purpose |
| Filter |
The LLM decides when to call it on its own — no code you have to write in the host.
Related MCP server: Agentic RAG MCP Server
You need a ZettaQuant API key with the vslm scope. Get one at zettaquant.ai (or ask your account contact).
Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"zettaquant-vslm": {
"command": "uvx",
"args": ["zettaquant-vslm-mcp"],
"env": {
"ZQ_API_KEY": "<your api key>"
}
}
}
}Restart Claude Desktop. The tools appear under the "Tools" menu.
Edit ~/.cursor/mcp.json:
{
"mcpServers": {
"zettaquant-vslm": {
"command": "uvx",
"args": ["zettaquant-vslm-mcp"],
"env": { "ZQ_API_KEY": "<your api key>" }
}
}
}Restart Cursor.
In ~/.config/zed/settings.json:
{
"context_servers": {
"zettaquant-vslm": {
"command": {
"path": "uvx",
"args": ["zettaquant-vslm-mcp"],
"env": { "ZQ_API_KEY": "<your api key>" }
}
}
}
}Any host that supports the standard mcpServers config shape works — use the same command + args + env block as above.
Variable | Required | Default | Notes |
| Yes | — | Your ZettaQuant API key. Must have the |
|
| Override for staging or a private gateway. |
Once installed, just ask naturally. Some prompts that will trigger vslm_predict:
"Here are 40 sentences from Apple's Q3 earnings call. Pull out the ones about AI capex plans."
"Filter these log lines down to anything related to lateral movement."
"I pasted a 10-K risk section. Only show me sentences about supply-chain exposure."
The model calls vslm_predict under the hood, gets back the relevant sentences, and works from those — cheaper and more precise than reading the full input.
uv venv
uv pip install -e .
export ZQ_API_KEY="..."
python -m zettaquant_vslm_mcpThe server speaks JSON-RPC on stdin/stdout. To poke it manually, use the MCP Inspector:
npx @modelcontextprotocol/inspector uvx zettaquant-vslm-mcp"ZQ_API_KEY is not set" in the host logs → the env block in your MCP config didn't propagate. Confirm the config file path and restart the host.
401 in tool output → key is valid but wrong. Try it directly: curl -H "x-api-key: $ZQ_API_KEY" https://api.zettaquant.ai/v1/usage/me.
ZettaQuant access denied (403) → your key doesn't have the vslm scope. Contact ZettaQuant.
ZettaQuant quota exceeded (429) → you hit your per-period cap; the error message includes the reset time.
MIT.
Filter a list of sentences to only those relevant to query.
Use this BEFORE feeding noisy context (earnings-call transcripts, news articles, long reports, log lines) to an LLM; it typically cuts token spend without losing important context. Chain it with your own language model.
Args: sentences: raw input sentences; ~2000 per call is comfortable. query: natural-language description of the topic to filter for (e.g. "AI capex plans", "rate cuts", "supply chain risk").
Returns: dict with: relevant_sentences: sentences that passed the filter, original order. total_sentences, relevant_count: counts to compute savings. topic_used: the topic string the model actually filtered against. topic_source: "zettaquant" (server-derived) or "caller" (you supplied). model_id: which V-SLM head handled the request.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| sentences | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on the full burden and delivers rich behavioral detail: it preserves original ordering, provides counts, exposes whether the topic came from the server or the caller, and identifies the model head via model_id. The '~2000 per call is comfortable' note adds practical capacity guidance. Nothing contradicts external signals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into Purpose, Usage, Args, and Returns sections, making it scannable. Every sentence adds useful information, from the token-spend motivation to the exact return fields. It is detailed but not verbose, and the most important usage guidance appears immediately after the one-line purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no annotations and no schema descriptions, the description covers everything an agent needs: what the tool does, when to use it, how to format each parameter, scale expectations, and the complete return structure. The only minor omissions are error behavior and rate limits, but those are not essential to correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, yet the description fully compensates. It explains that sentences are raw inputs, suggests a comfortable batch size, and clarifies query as a natural-language topic with concrete examples ('AI capex plans', 'rate cuts'). This is materially more than the bare schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific, action-oriented statement: 'Filter a list of sentences to only those relevant to `query`.' This clearly identifies a verb, target resource, and selection criterion. Even without siblings, the scope is unambiguous and distinct from generic 'predict' or 'classify' tool interpretations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool: 'Use this BEFORE feeding noisy context ... to an LLM' and explains the benefit of cutting token spend. It also advises chaining it with a language model. However, it does not state when not to use it or mention any alternatives, so it falls slightly short of full 5-level guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.1vslm_predictOnly one tool exists, so there is no possibility of selecting the wrong tool for a task. The tool's purpose is clearly defined as relevance filtering.
With a single tool, there is no internal naming pattern to violate. The name 'vslm_predict' is readable and action-oriented, though it uses noun-verb ordering rather than the more common verb-noun style.
One tool is below the usual 3-15 range, but it is a dedicated single-purpose utility specialized for sentence relevance filtering. The count feels slightly thin rather than excessive or trivial.
For the stated purpose of filtering noisy sentences before LLM ingestion, the tool provides the core operation plus useful metadata like counts and model info. There is no obvious missing operation within this narrow, well-defined domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server for LLM cost estimation, model comparison, and budget-aware routing.
Reddit & X data for AI agents over MCP. Semantic search, hosted, no Reddit API.
Free OpenAI-compatible inference with signed provenance receipts and 3 focused MCP tools.
A paid remote MCP for OpenAI Codex context compressor, built to return verdicts, receipts, usage log
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ZettaQuant/zettaquant-vslm-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
