What can you do with this server?

The Alephant MCP server provides AI cost analytics and virtual key management for Alephant BYO-KEY, usable from MCP-compatible hosts like Cursor and Claude Desktop. It operates in two modes: All Modes * Check API Connectivity — Verify the Alephant API is reachable and credentials are valid * Usage Summary — Total spend, request counts, and token usage for a chosen period (24h, 7d, 30d, or billing cycle) * Daily Costs — Day-by-day AI spend breakdown * Cost by Model — Spend and request volume broken down by AI model * List Available Models — Discover accessible AI models under the current credential scope Virtual Key (VK) Mode * View virtual key scope, limits, and accessible resources * Check budget status and remaining allowance * Browse recent API requests (with pagination) Manager Mode (Personal Access Token) * Workspace overview, budget status, and subscription info * Manage virtual keys (create, update budget, revoke) * Agent, member, and department analytics * Set budget policies and view live 24h data * Advanced insights: cost anomaly diagnosis, executive dashboards, spend drill-downs, idle resource detection, and entity period comparisons * Pre-built prompts for cost audit reports and optimization

Alephant MCP

Official

by AlephantAI

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Alephant MCP Server

Model Context Protocol server for Alephant BYO-KEY: FinOps metrics, virtual keys, and workspace analytics from Cursor, Claude Desktop, or any MCP host.

Modes

Mode	Environment	Tools
VK	`ALEPHANT_VIRTUAL_KEY`	Cockpit-scoped usage + 3 VK tools (8 tools total incl. shared)
Manager	`ALEPHANT_PAT` + `ALEPHANT_WORKSPACE_ID`	Workspace-wide management (27 tools total incl. shared)

PAT takes precedence when ALEPHANT_PAT is non-empty. If neither VK nor PAT is set, the process exits with an error (no mock data).

Required (both modes): ALEPHANT_API_BASE_URL
Optional: ALEPHANT_RATE_LIMIT_RPM (default 60, use 0 to disable client-side throttling)

Windows / `npx` troubleshooting

From this repo’s root (alephant-mcp/): do not use npx -y @alephantai/mcp to “smoke test” the published package. npm treats the current directory as the local @alephantai/mcp project and does not link the root package’s bin into node_modules/.bin, so Windows then fails with 'alephant-mcp' is not recognized (or the Chinese CMD equivalent).

Use one of these instead while developing in the clone:

npm start
# or
node .\bin\alephant-mcp.js

To verify npx the same way end users do, run it from any other directory (e.g. the parent folder):

cd ..
npx -y @alephantai/mcp

From a normal project folder (after npm install @alephantai/mcp), you can also run:

node .\node_modules\@alephantai\mcp\bin\alephant-mcp.js

If npx -y @alephantai/mcp still fails outside the clone, try:

npx --yes --package=@alephantai/mcp alephant-mcp

Published packages 0.0.2+ include the bin/alephant-mcp.js shim for reliable npm bin resolution when installed from the registry.

Related MCP server: TokenSaver MCP

MCP client config

Alephant MCP is a local stdio server. Use one server entry per credential scope. For multiple workspaces, create multiple entries with different names and environment variables.

Cursor / Claude Desktop

Virtual Key (read-only / scoped cockpit):

{
  "mcpServers": {
    "alephant": {
      "command": "npx",
      "args": ["-y", "@alephantai/mcp"],
      "env": {
        "ALEPHANT_API_BASE_URL": "https://alephant.io",
        "ALEPHANT_VIRTUAL_KEY": "vk-..."
      }
    }
  }
}

Personal Access Token (manager):

{
  "mcpServers": {
    "alephant-workspace-a": {
      "command": "npx",
      "args": ["-y", "@alephantai/mcp"],
      "env": {
        "ALEPHANT_API_BASE_URL": "https://alephant.io",
        "ALEPHANT_PAT": "pat_...",
        "ALEPHANT_WORKSPACE_ID": "00000000-0000-0000-0000-000000000000"
      }
    }
  }
}

Use separate mcpServers entries per workspace when you have multiple PATs.

Codex

Add a stdio MCP server in ~/.codex/config.toml:

[mcp_servers.alephant]
command = "npx"
args = ["-y", "@alephantai/mcp"]
env = {
  ALEPHANT_API_BASE_URL = "https://alephant.io",
  ALEPHANT_VIRTUAL_KEY = "vk-..."
}
startup_timeout_sec = 20
tool_timeout_sec = 120

For Manager mode, replace the VK env with:

env = {
  ALEPHANT_API_BASE_URL = "https://alephant.io",
  ALEPHANT_PAT = "pat_...",
  ALEPHANT_WORKSPACE_ID = "00000000-0000-0000-0000-000000000000"
}

Verify with:

codex mcp list
codex mcp get alephant

OpenCode

Add a local MCP server under mcp in your OpenCode config, for example opencode.json:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "alephant": {
      "type": "local",
      "command": ["npx", "-y", "@alephantai/mcp"],
      "enabled": true,
      "environment": {
        "ALEPHANT_API_BASE_URL": "https://alephant.io",
        "ALEPHANT_VIRTUAL_KEY": "vk-..."
      }
    }
  }
}

For Manager mode, use ALEPHANT_PAT and ALEPHANT_WORKSPACE_ID in environment instead of ALEPHANT_VIRTUAL_KEY.

Claude Code

Use the CLI to add Alephant as a local stdio server:

claude mcp add-json alephant '{"type":"stdio","command":"npx","args":["-y","@alephantai/mcp"],"env":{"ALEPHANT_API_BASE_URL":"https://alephant.io","ALEPHANT_VIRTUAL_KEY":"vk-..."}}' --scope user
claude mcp list
claude mcp get alephant

For a shared project config, create .mcp.json in the project root:

{
  "mcpServers": {
    "alephant": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@alephantai/mcp"],
      "env": {
        "ALEPHANT_API_BASE_URL": "https://alephant.io",
        "ALEPHANT_VIRTUAL_KEY": "vk-..."
      }
    }
  }
}

For Manager mode, replace the VK env with ALEPHANT_PAT and ALEPHANT_WORKSPACE_ID.

CLI audit

npx --yes --package=@alephantai/mcp alephant-mcp --audit

VK: prints cockpit scope + usage-summary (billing cycle).
Manager: prints workspace id + GET /api/v1/analytics/overview.

Tools (summary)

Shared (both modes): check_alephant_connection, get_usage_summary, get_daily_costs, get_cost_by_model, list_available_models
VK only: get_my_scope, get_my_budget, get_my_recent_requests
Manager only: get_workspace_overview, get_workspace_budget_status, list_virtual_keys, create_virtual_key, update_key_budget, revoke_virtual_key, list_agents, get_agent_analytics, list_members, get_member_analytics, list_departments, get_department_analytics, get_subscription_info, set_budget_policy, get_live_24h, get_usage_timeseries, get_sparklines, diagnose_cost_anomaly, get_executive_dashboard, drill_down_spend, find_idle_resources, compare_entity_periods

get_request_logs is not included (JWT-only backend route).

Prompts & resources

cost_audit_report — both modes
cost_optimization — manager only

Documentation

中文：在 AI Agent 中如何使用 MCP — 自然语言提问示例、/alephant-… 快捷模板、工具对照表
Marketplace submission: see docs/marketplace-submission.md for official MCP Registry, Smithery, and Glama submission notes.

Development

npm install
npm test
npm run build

Package

Published as @alephantai/mcp (alephant-mcp binary).

Available Tools

8 tools

check_alephant_connectionA

Read-onlyIdempotent

Checks Alephant API connectivity and credential usability for the current MCP mode.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds value by specifying that it checks connectivity and credential usability for the current MCP mode, providing context beyond annotations.

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 a single, clear sentence that efficiently conveys the purpose with no wasted words.

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 simplicity (no parameters, no output schema) and the annotations, the description is sufficient. It covers the core purpose, though additional detail on what exactly is checked or the response could enhance completeness.

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?

The tool has zero parameters, so the description need not add parameter information. Baseline score of 4 applies as it adds no unnecessary detail.

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 checks Alephant API connectivity and credential usability, using a specific verb and resource. It distinguishes from sibling tools that focus on costs, models, etc.

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?

The description does not explicitly say when to use this tool versus alternatives, but implies it is for verifying connectivity before other operations. No exclusions or alternatives are mentioned.

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

get_cost_by_modelA

Read-onlyIdempotent

Breaks down AI spend and request volume by model for the selected period.

ParametersJSON Schema

Name	Required	Description	Default
`period`	No	Aggregation window	billing_cycle

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint true and idempotentHint true. Description adds that it returns spend and request volume by model, which is useful but does not disclose additional behaviors like empty results or pagination.

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?

Single sentence, front-loaded verb 'Breaks down', zero waste. Highly concise and structured.

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?

For a simple tool with one parameter and no output schema, the description is mostly complete: it specifies the grouping (by model) and the metrics (spend and request volume). Lacks details on return format but adequate.

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

Parameters3/5

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

Schema coverage is 100%; the description does not add meaning to the period parameter beyond what the schema provides. Baseline 3 is appropriate.

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 clearly states it breaks down AI spend and request volume by model, with a specific verb and resource. It distinguishes from siblings like get_daily_costs (no model breakdown) and get_usage_summary.

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?

Implied usage context: use this when you need cost per model. However, no explicit when-to-use or when-not-to-use guidance, nor alternatives mentioned.

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

get_daily_costsA

Read-onlyIdempotent

Returns daily AI spend for the selected period.

ParametersJSON Schema

Name	Required	Description	Default
`period`	No	Aggregation window	billing_cycle

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, destructiveHint, and idempotentHint, so the safety profile is clear. The description adds no further behavioral context (e.g., whether costs are grouped, currency, or pagination). Given the annotations cover the main safety aspects, a score of 3 is appropriate.

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 a single sentence with no wasted words. It is front-loaded and efficiently communicates the tool's purpose.

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?

Despite the tool being simple (one optional parameter, no output schema), the description does not detail the return format or structure of the daily costs. For a cost tool, knowing the breakdown (e.g., per model, per scope) would be valuable. The description is adequate but could be more complete.

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

Parameters3/5

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

Schema description coverage is 100%, and the parameter 'period' has a clear description and enum. The tool description does not add extra meaning beyond what the schema provides, so the baseline of 3 is justified.

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 returns daily AI spend for a selected period. It uses a specific verb ('Returns') and resource ('daily AI spend'), and the context ('selected period') is clear. It distinguishes itself from siblings like get_cost_by_model and get_usage_summary.

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

Usage Guidelines2/5

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

No usage guidance is provided. The description does not indicate when to use this tool versus alternatives such as get_cost_by_model (which provides per-model breakdown) or get_usage_summary (which might aggregate differently). There are no when-to-use or when-not-to-use instructions.

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

get_my_budgetA

Read-onlyIdempotent

Returns budget status for the current virtual key.

ParametersJSON Schema

Name	Required	Description	Default
`period`	No	Budget window for cockpit/budget-status query param	billing_cycle

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds the scope 'for current virtual key', which is useful but not deeply behavioral. 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?

Single sentence, no extraneous text. Perfectly concise.

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 one optional parameter, no output schema, and rich annotations, the description is sufficient. It covers the purpose and scope without gaps.

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

Parameters3/5

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

Schema description coverage is 100% (the period parameter is fully described in schema). The tool description does not add extra parameter context, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns budget status for the current virtual key. This is specific and distinguishes from siblings like get_cost_by_model or get_daily_costs, though it doesn't explicitly call out the difference.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives (e.g., get_daily_costs for cost breakdown, get_usage_summary for usage). The description does not provide context for selection.

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

get_my_recent_requestsB

Read-onlyIdempotent

Returns recent requests made with the current virtual key.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`offset`	No

TDQS

B3/5.0

Behavior3/5

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

Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds no additional behavioral context (e.g., ordering, pagination, rate limits), but given the strong annotations, a score of 3 is appropriate.

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 a single concise sentence, front-loading the core functionality. However, it could be expanded to improve completeness without sacrificing conciseness.

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

Completeness2/5

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

Given two parameters with no schema descriptions and no output schema, the description omits critical details like pagination behavior, default ordering, and the definition of 'recent.' The strong annotations mitigate safety concerns but not completeness.

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

Parameters1/5

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

Schema description coverage is 0%, yet the description fails to explain the meaning or usage of limit and offset parameters. This is a significant gap for a paginated query tool.

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 specifies the action ('returns recent requests') and the scope ('with the current virtual key'), making it distinct from sibling tools like get_my_budget or get_usage_summary.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives (e.g., check_alephant_connection or get_cost_by_model). The description only states what it does without contextual usage advice.

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

get_my_scopeA

Read-onlyIdempotent

Returns the current virtual key scope, limits, and accessible resources.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already provide readOnlyHint and idempotentHint. The description adds value by specifying exactly what is returned (scope, limits, accessible resources), reinforcing the safe read behavior without contradicting annotations.

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 a single sentence of 10 words, efficiently stating the purpose. It is front-loaded with the verb 'Returns' and contains no extraneous information.

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 the tool has no parameters, annotations indicate safety, and no output schema exists, the description sufficiently explains what the tool does. An agent can correctly infer that calling this tool is safe and returns scope information.

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?

The input schema has zero parameters with 100% coverage. The description does not need to add parameter information. Baseline of 4 is appropriate as no parameter details are required.

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 uses the verb 'Returns' and specifies the resource as 'current virtual key scope, limits, and accessible resources'. It clearly distinguishes from siblings like get_my_budget or get_usage_summary by focusing on scope and limits.

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?

The description does not provide explicit guidance on when to use this tool versus alternatives. Usage is implied as a simple read of scope information, but no exclusions or contexts are given.

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

get_usage_summaryA

Read-onlyIdempotent

Returns total spend, requests, and token usage for the selected period.

ParametersJSON Schema

Name	Required	Description	Default
`period`	No	Aggregation window	billing_cycle

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint and idempotentHint, so the description's basic statement is consistent but does not add additional behavioral context such as caching or permissions.

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 a single sentence that efficiently conveys core functionality without extraneous information, front-loaded with the key action.

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?

For a simple read-only tool with one parameter and full annotation coverage, the description provides essential information about what is returned and the period parameter. It could mention aggregation scope, but it is functional.

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

Parameters3/5

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

Schema coverage is 100% with a description and enum for the 'period' parameter. The description does not elaborate on parameter semantics, but the schema already provides sufficient information.

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 returns total spend, requests, and token usage for a selected period, using a specific verb and resource. This distinguishes it from siblings like get_cost_by_model or get_daily_costs.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus its siblings or alternatives. The description lacks context about use cases or exclusions.

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

list_available_modelsA

Read-onlyIdempotent

Lists models available through Alephant for the current credential scope.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds context about 'current credential scope', which is valuable beyond annotations but does not elaborate on behavior like response format or speed.

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?

Single sentence conveying essential information with no wasted words. The structure is front-loaded with verb and resource.

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?

Lacking output schema, the description could hint at return values (e.g., model names, IDs). For a list tool, this is a minor gap. Otherwise adequate for a simple tool with no parameters.

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?

The input schema has zero parameters, so baseline is 4. The description correctly indicates no parameters are needed, and no additional meaning is required.

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 verb 'Lists', the resource 'models', and the context 'available through Alephant for the current credential scope'. It distinguishes the tool from siblings like 'get_cost_by_model' and 'check_alephant_connection' by focusing on listing all available models.

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

Usage Guidelines2/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 versus alternatives. While the purpose implies listing all models, the description does not mention when to use it (e.g., before selecting a model) or when not to. Sibling tools suggest other operations, but no comparison is provided.

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.

8 tool updatesv0.1.2May 16, 2026
- First observedcheck_alephant_connection
- First observedget_cost_by_model
- First observedget_daily_costs
- First observedget_my_budget
- First observedget_my_recent_requests
- First observedget_my_scope
- First observedget_usage_summary
- First observedlist_available_models

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Disambiguation5/5

Each tool targets a distinct aspect: connection check, cost breakdowns (by model, daily, total), budget status, recent requests, scope, and model listing. No two tools have overlapping purposes.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (e.g., check_alephant_connection, get_cost_by_model, list_available_models) with clear, predictable naming.

Tool Count5/5

With 8 tools, the server is well-scoped for monitoring and managing Alephant API usage. The count is neither too sparse nor excessive.

Completeness4/5

The set covers essential monitoring needs (connection, costs, budget, requests, scope, models). Missing are management actions like updating budgets or keys, but the core monitoring surface is complete.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

TokenOracle
com.guffeyholdings
Hosted MCP server for LLM cost estimation, model comparison, and budget-aware routing.
Finance Monitoring
2
SandBase
io.github.sandbaseai
Connect MCP clients to 2,000+ AI models without managing provider API keys.
AI & Machine Learning Agent Orchestration
1116
anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
ClawLinkOAuth
dev.claw-link
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
App Automation Workplace & Productivity
24

Related MCP Servers

Outsource MCP
Agent Orchestration Code Execution
gwbischof
A
license
A
quality
D
maintenance
An MCP server that enables AI applications to access 20+ model providers (including OpenAI, Anthropic, Google) through a unified interface for text and image generation.
Updated a year ago (2025-05-28 21:36 UTC)
2
30
MIT
TokenSaver MCP
AI & Machine Learning Developer Tools
pozii
A
license
A
quality
C
maintenance
An MCP server that reduces AI API costs by up to 97% through token measurement, compression, caching, and pruning, all without changing prompts.
Updated 3 months ago (2026-06-21 13:19 UTC)
10
1
Apache 2.0
Multi-Provider LLM MCP Server
itachiuchihadev
F
license
A
quality
C
maintenance
Unified MCP server for querying multiple LLM providers (Gemini, OpenAI, Anthropic, etc.) with advanced routing, cost optimization, and fallback resilience.
Updated 2 months ago (2026-07-18 15:32 UTC)
2
15
-
llm-router-mcpofficial
AI & Machine Learning Agent Orchestration
rebaselabs-framework
A
license
Not graded
quality
D
maintenance
MCP server that routes AI chat requests to the best available provider (Anthropic, OpenAI, Groq, etc.) with automatic fallback, budget caps, and model-tier routing.
Updated 6 months ago (2026-03-19 19:35 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/AlephantAI/alephant-mcp'

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

Alephant MCP Server

Modes

Windows / npx troubleshooting

MCP client config

Cursor / Claude Desktop

Codex

OpenCode

Claude Code

CLI audit

Tools (summary)

Prompts & resources

Documentation

Development

Package

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

llm-router-mcpofficial

Latest Blog Posts

MCP directory API

Windows / `npx` troubleshooting