wallet-tracker
Server Details
KOL, smart money & whale wallets API on Solana, BNB, Base, ETH: Wallet tracker, Leaderboard
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 9 of 9 tools scored.
Most tools have clearly distinct purposes, but get_wallet_tracker and get_wallet_history both provide trading statistics, which could cause confusion. However, descriptions clarify that one is period-specific and the other is lifetime, reducing ambiguity.
The naming convention is mostly consistent with a 'get_' prefix, but two tools deviate: list_wallets and lookup_wallet. This minor inconsistency is acceptable but prevents a perfect score.
With 9 tools, the server is well-scoped for its purpose of wallet tracking. Each tool addresses a distinct query need, and there is no bloat or deficiency.
The tool set covers all typical read operations: listing wallets, looking up addresses, leaderboard, history, holdings, connections, and PnL calendar. No obvious gaps exist for the intended domain.
Available Tools
9 toolsget_leaderboardARead-onlyIdempotentInspect
Top tracked wallets ranked by trading volume for a chain, wallet type and
period. Use for "best Solana KOLs today", "top whales this week", etc.
Returns a leaderboard array with each wallet's profile and period stats
(realized PnL, volume, win rate, trade counts).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max number of wallets to return. | |
| period | No | Time window: 6h, 1d, 7d or 30d. | 1d |
| blockchain | Yes | Blockchain network: solana, bnb, base or eth. | |
| wallet_type | No | Wallet category: kol, smart or whale. | kol |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds that results are ranked by trading volume and lists output fields (realized PnL, volume, win rate, trade counts), complementing the annotations without contradiction.
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?
Two concise sentences. The first states the core function and example use cases; the second describes the output. No wasted words, front-loaded with essential information.
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?
Given the presence of output schema and complete parameter descriptions, the description covers the tool's purpose, usage, and output adequately. It is fully sufficient for an agent to understand when and how to invoke the tool.
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?
Schema description coverage is 100%, so the main description does not need to add much. It provides example period and wallet type values in the usage examples, but these are already in the schema. Baseline score of 3 is appropriate.
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?
Description clearly states the tool returns wallets ranked by trading volume for a chain, wallet type, and period. It provides specific use-case examples like 'best Solana KOLs today', distinguishing it from sibling tools that focus on individual wallet data.
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 advises when to use the tool via example queries ('Use for...'), giving clear context. However, it does not explicitly state when NOT to use it or directly compare to alternatives, but the examples suffice for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pnl_calendarARead-onlyIdempotentInspect
Daily and monthly realized-PnL calendar for a wallet, covering its full
tracked history (all months, plus the current month live).
Returns a months array with per-day realized PnL and monthly summaries.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Wallet address (Solana base58 or 0x… for EVM chains). | |
| blockchain | Yes | Blockchain network: solana, bnb, base or eth. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. Description adds that it returns a months array with per-day PnL and monthly summaries, and covers full history plus current month live.
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?
Two short sentences, no wasted words, key information front-loaded. Ideal conciseness.
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?
Output schema exists, so return values are documented. Description briefly mentions return structure, which is sufficient for this simple data retrieval tool.
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?
Schema has 100% coverage with descriptions for both parameters. Description does not add additional parameter info, but schema itself is sufficient.
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 clearly states it provides daily and monthly realized-PnL calendar for a wallet, covering full tracked history. It distinguishes from sibling tools like 'get_wallet_history' by focusing on PnL calendar.
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?
No explicit when-to-use or when-not-to-use guidance, nor mention of alternatives. Usage is implied by the purpose but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_startedARead-onlyIdempotentInspect
How to use CabalSpy: where to get a free API key (1000 requests, no cost),
pricing and documentation. Call this first if you don't have an API key yet
or if another tool returned an auth error.
Returns a JSON object with: what_is_cabalspy, free_test_key, pricing, docs,
how_to_set_key, chains, wallet_types and periods.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about the tool's role in authentication and onboarding, and specifies the return value structure (fields like free_test_key, pricing, docs). No contradictions with annotations.
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 brief (three sentences) and front-loaded with the key information. It could be slightly more concise, but it effectively conveys the essential usage and return details without redundancy.
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?
Given zero parameters and an existing output schema, the description fully covers the tool's purpose, usage context, and return values. It provides sufficient information for an agent to select and invoke this tool correctly.
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 no parameters (0 params, 100% coverage). Per rubric, baseline is 4. The description adds value by explaining the return value fields, but this is not parameter-related. No further improvement needed.
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 clearly states the tool's purpose: to provide information on how to use CabalSpy, including getting a free API key, pricing, and documentation. It distinguishes itself from sibling tools (e.g., get_leaderboard, get_wallet_history) which require an API key, making it ideal for initial setup or after auth errors.
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?
Explicit instructions are given: 'Call this first if you don't have an API key yet or if another tool returned an auth error.' This clearly indicates when to use this tool versus its siblings, which would fail without a valid key.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_wallet_connectionsARead-onlyIdempotentInspect
Find other tracked wallets that share traded tokens with the given wallet
over the last 30 days, ranked by number of shared tokens.
Returns a connections array, each with shared_tokens and an overlap_score.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max number of connections to return. | |
| address | Yes | Wallet address (Solana base58 or 0x… for EVM chains). | |
| blockchain | Yes | Blockchain network: solana, bnb, base or eth. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: the 30-day window, ranking logic, and output fields (shared_tokens, overlap_score). Annotations already indicate read-only, idempotent, non-destructive behavior, so no contradiction.
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?
Two sentences concisely convey purpose, behavior, and output structure with no redundancy. Every sentence adds value.
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?
Given the tool's complexity (3 params, output schema), the description covers time window, ranking, and return fields. Omitted details like error cases are minor, and the output schema likely covers return structure.
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?
Schema coverage is 100% with adequate parameter descriptions. The tool description provides the overall purpose but does not add significant parameter-specific meaning beyond the schema, so baseline 3 is appropriate.
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 explicitly states the tool finds other tracked wallets sharing traded tokens with an input wallet, over a 30-day window and ranked by shared tokens. This clearly differentiates it from sibling tools like get_wallet_history or lookup_wallet.
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 implies usage for discovering wallet connections and specifies time constraints (last 30 days) and ranking, providing clear context. However, it does not explicitly mention when not to use this tool or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_wallet_historyARead-onlyIdempotentInspect
Complete LIFETIME trading history for a wallet: aggregated stats, per-token
overview, win-rate distribution and a paginated list of every transaction.
For a full export, call repeatedly with pagination.next_cursor until it is null.
Returns profile, lifetime_stats, win_rate_distribution, token_overview,
trades and a pagination object.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Trades per page, 1-1000. | |
| cursor | No | Pagination cursor from the previous response. Omit for the first page. | |
| address | Yes | Wallet address (Solana base58 or 0x… for EVM chains). | |
| blockchain | Yes | Blockchain network: solana, bnb, base or eth. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds return structure details (profile, stats, distributions) and pagination behavior, enhancing transparency.
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?
Two sentences, front-loaded with core purpose, then pagination instruction. Every sentence is essential and well-structured.
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?
Given output schema exists, annotations are present, and schema covers parameters fully, the description is complete for a read-only tool with pagination.
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?
Schema coverage is 100% with descriptions. The description adds value by explaining how to use pagination cursor for full export, beyond the schema's basic description.
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?
Clearly states it retrieves complete lifetime trading history with aggregated stats, per-token overview, win-rate distribution, and paginated transactions. Distinct from sibling tools like get_wallet_holdings.
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?
Provides explicit pagination guidance for full export. While it doesn't explicitly contrast with siblings, the context makes it clear this is the comprehensive history tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_wallet_holdingsARead-onlyIdempotentInspect
Current on-chain token holdings of a wallet (amounts, not USD). If 'loading'
is true, the data is still warming up — call again shortly.
Returns an active_holdings object with the token list and a last_updated time.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Wallet address (Solana base58 or 0x… for EVM chains). | |
| blockchain | Yes | Blockchain network: solana, bnb, base or eth. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Disclosures loading behavior beyond annotations (readOnlyHint, idempotentHint, etc.), adding value. Could elaborate on data freshness guarantees or limits.
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?
Two sentences, purpose fully front-loaded, no extraneous words.
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?
With 2 simple params, clear output structure mentioned, and explanation of loading, description is complete and clear.
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?
Schema covers 100% of parameters with descriptions; description adds no new param-specific info beyond schema, meeting baseline for high schema coverage.
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 clearly states it retrieves current on-chain token holdings with amounts (not USD), distinguishes from siblings like get_wallet_history or get_wallet_tracker.
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?
Provides actionable guidance on the loading state ('call again shortly'), but does not explicitly state when to use vs alternatives or mention prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_wallet_trackerARead-onlyIdempotentInspect
Detailed period stats for ONE wallet: realized PnL, win rate, volume, trade
counts, active tokens, win-rate distribution and recent trades.
Returns a profile plus period_stats, period_win_rate_distribution,
period_active_tokens and period_trades.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | Time window: 6h, 1d, 7d or 30d. | 1d |
| address | Yes | Wallet address (Solana base58 or 0x… for EVM chains). | |
| blockchain | Yes | Blockchain network: solana, bnb, base or eth. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds behavioral context by detailing the returned sections (profile, period_stats, etc.) and confirming it operates on one wallet. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the key purpose and followed by a clear list of return components. Every sentence adds value with no redundancy.
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?
Given the presence of an output schema (not shown but noted), the description appropriately lists the main return sections. It covers the purpose, parameters, and behavior adequately for a read-only tool with extensive annotations.
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?
Schema description coverage is 100%, with each parameter already described (period as time window, address format, blockchain as network). The description adds no new parameter meaning beyond what the 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 clearly states it provides 'Detailed period stats for ONE wallet', listing specific metrics like realized PnL, win rate, volume. It uses a specific verb (get) and resource (wallet tracker stats), and implicitly distinguishes from sibling tools like get_wallet_history and list_wallets by emphasizing 'ONE wallet'.
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 implies usage for obtaining detailed period stats for a single wallet, and the context of sibling tools helps differentiate. However, it lacks explicit guidance on when not to use it or direct mentions of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_walletsARead-onlyIdempotentInspect
List all tracked wallets for a chain and wallet type (paginated).
Returns a wallets array plus a pagination object with the next cursor.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max number of wallets per page. | |
| cursor | No | Pagination cursor from the previous response. Omit for the first page. | |
| blockchain | Yes | Blockchain network: solana, bnb, base or eth. | |
| wallet_type | Yes | Wallet category: kol, smart or whale. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, establishing safe, non-destructive behavior. The description adds useful detail: paginated results and the exact return format (wallets array + pagination object with next cursor). No contradictions with annotations.
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 extremely concise—two sentences that immediately state the purpose and key behaviors (pagination, return structure). No extraneous words; every sentence earns its place.
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?
Given the tool's moderate complexity (4 params, 2 required) and presence of an output schema, the description adequately covers the core functionality. It specifies the return format, which, combined with the output schema, provides sufficient understanding for tool 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?
Input schema coverage is 100%, so baseline is 3. The description does not add significant meaning beyond the schema—it only echoes the required params (chain, wallet type) and pagination cursor. Schema already describes each parameter's type, defaults, and examples.
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 clearly states 'List all tracked wallets for a chain and wallet type (paginated)', specifying the verb (list), resource (tracked wallets), and scope (by chain and wallet type). This effectively distinguishes it from sibling tools like get_wallet_holdings or get_wallet_history, which focus on individual wallets or specific analytics.
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 provides basic usage context by mentioning pagination and the return structure (wallets array + pagination object with next cursor). However, it does not explicitly state when to use this tool over alternatives or include exclusions, leaving room for improvement in guiding selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_walletARead-onlyIdempotentInspect
Check whether a wallet address is tracked by CabalSpy across all chains and
types. Returns 'found: true' plus the wallet's profile (name, chain, type)
if tracked, otherwise 'found: false'.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Wallet address (Solana base58 or 0x… for EVM chains). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, etc. The description adds clarity on the return format ('found: true/false' plus profile) and scope ('all chains and types'), which is useful 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with purpose and return behavior. Every word earns its place.
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?
Given the tool's simplicity (one parameter, output schema present), the description is complete enough. It specifies the input, return behavior, and scope.
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?
Schema description coverage is 100% for the single parameter, and the description does not add additional meaning beyond what the schema already 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 uses a specific verb 'Check whether' with a clear resource 'wallet address is tracked by CabalSpy across all chains and types', and explicitly states the return values. It distinguishes from siblings by focusing on tracking status.
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 implies when to use (to check if a wallet is tracked) but does not explicitly state when not to use or provide alternatives among siblings like get_wallet_tracker.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!