Skip to main content
Glama
MukundaKatta

agentfit-mcp

by MukundaKatta
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
JavaScript
Local

agentfit-mcp

MCP server for @mukundakatta/agentfit. Lets Claude Desktop, Cursor, Cline, Windsurf, Zed, or any other MCP client estimate token counts and fit a chat history into a model's context budget on demand.

npx -y @mukundakatta/agentfit-mcp

Three tools:

  • count_tokens — estimate tokens in a string or chat-message array, with per-model estimator families (openai, anthropic, google, llama, default).

  • fit_messages — drop messages from a chat history until under a maxTokens budget. Supports drop-oldest, drop-middle, and priority strategies; honors preserveSystem, preserveFirstN, preserveLastN.

  • list_estimators — list the built-in estimator families.

Add to your client

Claude Desktop

Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "agentfit": {
      "command": "npx",
      "args": ["-y", "@mukundakatta/agentfit-mcp"]
    }
  }
}

Cursor

~/.cursor/mcp.json:

{
  "mcpServers": {
    "agentfit": {
      "command": "npx",
      "args": ["-y", "@mukundakatta/agentfit-mcp"]
    }
  }
}

Cline / Windsurf / Zed

Same shape as above. The server speaks plain MCP over stdio, so any client that supports stdio MCP servers will work.

Related MCP server: sessionmem

Tool examples

count_tokens:

{ "input": "hello world", "model": "claude-sonnet-4-6" }

Returns:

{ "tokens": 4, "model": "claude-sonnet-4-6" }

fit_messages:

{
  "messages": [
    { "role": "system", "content": "You are precise." },
    { "role": "user", "content": "long context..." },
    { "role": "assistant", "content": "..." },
    { "role": "user", "content": "final question" }
  ],
  "maxTokens": 8000,
  "model": "claude-sonnet-4-6",
  "preserveSystem": true,
  "preserveLastN": 2,
  "strategy": "drop-oldest"
}

Returns:

{
  "messages": [...],
  "dropped": [...],
  "tokens": { "before": 12000, "after": 7800, "budget": 8000 },
  "fit": true
}

fit_messages always returns a structured result and never throws across the wire: if the budget is unreachable even after dropping all non-protected messages, you get fit: false with the partial result so the caller can decide what to do.

Why a separate MCP server

@mukundakatta/agentfit is a zero-dependency JavaScript library. This package wraps it as an MCP server so it's accessible from inside any MCP-aware AI assistant: ask Claude "how many tokens is this transcript?" or "trim this chat to 8k tokens preserving the system prompt and last 2 turns" and the assistant calls these tools directly.

Sibling MCP servers

Part of the agent-stack series, all @mukundakatta/*-mcp:

License

MIT

Available Tools

3 tools
count_tokensA

Estimate tokens in a string or chat-message array. Fast, dependency-free, within ~10-20% of true tokenizer counts on English prose. Pass a model name to pick the right per-family estimator (openai, anthropic, google, llama, default).

ParametersJSON Schema
NameRequiredDescriptionDefault
inputYesString or array of chat messages.
modelNoOptional model name (e.g. "gpt-5", "claude-sonnet-4-6"). Picks the closest estimator family.
overheadNoPer-message overhead in tokens (default depends on model family, usually 4-6).

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, description carries full burden. It discloses it's fast, dependency-free, and within 10-20% accuracy. No side effects mentioned, but the tool is read-only by nature, so acceptable.

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

Conciseness5/5

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

Three short sentences, no fluff. Front-loaded with purpose, then efficiency claims, then model parameter guidance. Every sentence earns its place.

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

Completeness3/5

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

No output schema, so description should ideally state what is returned (likely a number). Missing that. 3 params covered well, but return value omission leaves a gap.

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 coverage is 100%, but description adds value: clarifies model parameter example families, overhead default range, and input types. Enriches beyond schema without redundancy.

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?

Description starts with 'Estimate tokens in a string or chat-message array,' clearly stating the verb and resource. It also adds context on speed and accuracy, making the purpose unmistakable.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool over siblings (fit_messages, list_estimators). It implies usage by mentioning model selection, but lacks when-not-to-use or alternative scenarios.

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

fit_messagesA

Drop messages from the input array until the total is under maxTokens. Three strategies: drop-oldest (default), drop-middle, priority (uses each message's priority field). Always returns a structured result with token counts before and after; never throws across the wire.

ParametersJSON Schema
NameRequiredDescriptionDefault
modelNoOptional model name for estimator selection.
messagesYesChat messages to fit.
overheadNoPer-message overhead in tokens.
strategyNoDrop strategy. Default drop-oldest.
maxTokensYesToken budget the result must come in under.
preserveLastNNoNever drop the last N messages of the input array. Default 0.
preserveFirstNNoNever drop the first N messages of the input array. Default 0.
preserveSystemNoDefault true: never drop messages with role === "system".

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description fully discloses behavior: it drops messages, provides three strategies, returns a structured result with token counts, and never throws errors. This covers safety and operational traits comprehensively.

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

Conciseness5/5

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

The description is concise, front-loaded with the main action, and each sentence adds value. No redundancy or filler.

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 8 parameters (2 required) and no output schema, the description explains the core behavior and return format (token counts) clearly. It does not detail every parameter but schema covers them. The strategies and error behavior are well described.

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 coverage is 100%, so baseline is 3. The description adds context beyond schema by explaining the three strategies and the meaning of the priority field, enhancing understanding of parameter usage.

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: dropping messages to fit under maxTokens. It lists three strategies, distinguishing it from sibling tools like count_tokens and list_estimators.

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 implicitly guides usage by describing the tool's function and strategies, but does not explicitly compare to siblings or state when not to use it. The sibling tools are sufficiently different to imply appropriate use cases.

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

list_estimatorsA

List the built-in estimator families this server knows about. Useful for picking a model alias when the exact model name isn't recognized.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior4/5

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

No annotations provided, but description clearly indicates a read-only listing operation. No contradictions.

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

Conciseness5/5

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

Two short, front-loaded sentences with no wasted words.

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 zero parameters and no output schema, the description fully explains the tool's purpose and use case.

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?

No parameters, so schema coverage is 100%. Description adds value by explaining the purpose of the output.

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?

Clearly states the verb 'list' and resource 'built-in estimator families'. The description also explains the utility for picking a model alias, distinguishing it from siblings like count_tokens and fit_messages.

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?

Explicitly indicates when to use the tool (when exact model name isn't recognized). No need for exclusions given simplicity.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 3 tool updatesv0.1.0
    • First observedcount_tokens
    • First observedfit_messages
    • First observedlist_estimators
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: counting tokens, fitting messages under a token limit, and listing available estimator families. No overlap or confusion.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (count_tokens, fit_messages, list_estimators), making them predictable and easy to understand.

Tool Count5/5

With 3 tools, the server is tightly scoped to token estimation and message fitting. Each tool earns its place, and the count is appropriate for this focused domain.

Completeness4/5

The tool surface covers core operations: counting tokens, fitting messages with multiple strategies, and listing estimators. A minor gap is the lack of a tool for direct model-specific tokenization, but the per-family estimator covers most use cases.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • llm-token-tracker

    wn01011
    A
    license
    B
    quality
    D
    maintenance
    Token usage tracker for OpenAI and Claude APIs with MCP (Model Context Protocol) support.
    6
    25
    5
    MIT

  • sessionmem

    catfish-1234
    A
    license
    A
    quality
    A
    maintenance
    Local-first MCP server that watches your coding sessions and injects a compact summary at the start of each new session. 85.6% token reduction, SQLite storage, no cloud. Works with Claude Code, Cursor, Cline, and Windsurf.
    13
    28
    8
    MIT

  • Tokenomics MCP

    JonThads
    A
    license
    A
    quality
    C
    maintenance
    Counts LLM prompt tokens and estimates API costs across OpenAI and Anthropic models directly inside MCP-compatible chat clients. Supports exact tokenization for OpenAI models and fallback approximation for Claude when no API key is present.
    4
    MIT

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/MukundaKatta/agentfit-mcp'

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