cryptosense-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct query type: single price lookup, trending list, global stats, top N, comparison, and portfolio calculation. Overlap is minimal, with trending and top_coins differing by search volume versus market cap.
Naming Consistency3/5
All names follow a consistent lowercase_with_underscores style, but the grammatical pattern is mixed: nouns (price, market_overview), gerund (trending), adjective+noun (top_coins), verb (compare), and compound noun (portfolio_value). No verb_noun pattern is established, though names remain readable.
Tool Count5/5
Six tools is well-scoped for a crypto market data server, fitting comfortably within the ideal 3-15 range. Each tool has a clear purpose without redundancy.
Completeness4/5
The surface covers single-coin pricing, market lists, global overview, comparison, and portfolio valuation, covering core workflows. Historical price data and detailed coin metadata are missing, but these are not essential to the server's apparent purpose.
Average 3.6/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are available, so the description carries the full burden of behavioral disclosure. It does not mention that the currency parameter can override USD, how unknown holdings are handled, whether an API key is needed, or any data-source/rate-limit details.
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?
A single, front-loaded sentence conveys the core action with no redundant words. It is concise and well-structured for quick agent parsing.
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?
The tool is simple, has a detailed schema, and an output schema exists, so the description need not explain return values. However, it lacks any context about when to choose this tool or how to handle edge cases, leaving some gaps for a fully informed invocation.
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%, so the baseline is 3. The description itself adds no parameter-level meaning and its 'USD' wording could be misleading given the currency parameter, but the schema already documents each parameter clearly.
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 verb 'calculate' and the resource 'crypto portfolio', and it distinguishes this tool from siblings like price or trending by focusing on aggregate valuation. However, it specifies 'USD value' while the schema's currency parameter allows other fiat currencies, creating minor ambiguity.
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?
Usage is implied: use this tool when you need a portfolio valuation rather than single-coin pricing. There is no explicit mention of alternatives or scenarios where another tool would be preferred, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose data source, request behavior, rate limits, or whether an API key is required or optional. The presence of an api_key parameter is not addressed, leaving operational behavior opaque.
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 compact and front-loaded with the main purpose, followed by a useful bullet-style list of deliverables and concrete example prompts. Every sentence contributes meaningful information without redundancy.
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?
The output schema handles return values, and the listed metrics give a good sense of the tool's scope. However, missing guidance on the api_key parameter and lack of behavioral or alternative-tool context leave the description only minimally complete.
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?
The input schema has one parameter, api_key, with 0% schema description coverage, and the description does not mention it at all. This fails to compensate for the low schema coverage, giving the agent no additional guidance on how or whether to supply the key.
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 a specific verb and resource: 'Get the global crypto market overview.' It then enumerates the included metrics (market cap, 24h volume, BTC/ETH dominance, active counts), which distinguishes it from sibling tools like price, trending, and top_coins.
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 example prompts give concrete usage context, such as asking for total crypto market cap or Bitcoin dominance. However, it does not explicitly mention when not to use the tool or direct users to alternatives, so it misses the top level of guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation ('Get') but does not mention authentication requirements, rate limits, or behavior with an invalid or missing API key. 'With price and stats' gives a minimal hint but is largely covered by the output schema.
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, front-loaded sentence with no redundant or irrelevant information. Every word contributes to the core purpose.
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?
The tool is simple, optional parameters are fully documented in the schema, and an output schema exists to detail return fields. The description is sufficient for basic use, though it could mention auth expectations; however, the structured data compensates for most 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?
The input schema provides 100% parameter coverage with descriptions for 'limit', 'api_key', and 'currency', so the baseline is 3. The description adds no additional parameter meaning beyond the schema, and it does not mention any parameter interplay or constraints.
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 a specific verb ('Get') and clearly defines the resource ('top N cryptocurrencies by market cap') with an outcome ('with price and stats'). It effectively distinguishes itself from siblings like 'price' and 'trending' by emphasizing market-cap ranking.
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 is given about when to use this tool versus alternatives such as 'trending' or 'market_overview'. The use case is only implied by the purpose statement, and no exclusions or alternative references are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the output fields but does not disclose the default currency behavior, the purpose of the api_key parameter, error handling, or any rate limits. The 'Get' verb implies a read operation but lacks deeper transparency.
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 two sentences long, front-loaded with a clear purpose, and followed by illustrative examples. Every sentence earns its place without unnecessary detail.
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 three parameters and an output schema, the description covers the core purpose and provides examples. It is missing usage guidelines and api_key semantics, but given the low complexity, it is nearly complete. The main gap is lack of explicit sibling differentiation.
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 0%, so the description must compensate. It adds meaning for 'coin' via 'any cryptocurrency' and for 'currency' via the EUR example, but it leaves the 'api_key' parameter entirely unexplained. This is partial compensation, not complete.
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 a specific verb 'Get' and clearly states the resource: current price, 24h change, market cap, and volume for any cryptocurrency. The example prompts demonstrate the tool's scope for individual coins, which distinguishes it from sibling tools like market_overview and top_coins that likely cover broader market data.
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 example prompts imply when to use the tool (e.g., when a user asks for a specific coin's price), but there is no explicit statement of when to use this tool versus alternatives, no exclusions, and no mention of sibling tools. Usage context is clear but guidance is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility for behavioral disclosure. It states the informational output, which is helpful, but it does not explicitly confirm the operation is read-only, mention authentication requirements beyond the api_key parameter, or disclose any rate limits, errors, or side effects. The 'compare' verb implies a safe operation, but this is under-specified.
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 two concise sentences, front-loaded with the primary action ('Compare...') and followed by a compact list of the displayed metrics. Every sentence adds value, with no redundant or filler content.
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?
The tool has a complete input schema and an output schema, so the description need not explain return values. It effectively covers the core function and the minimum coin count. It is slightly thin on usage guidance relative to siblings, but for a straightforward comparison tool with full schema coverage, it is adequately complete.
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 the baseline is 3. The description adds meaningful context by specifying 'two or more' for the coins parameter, a constraint not present in the schema (no minItems), and by clarifying the per-coin metrics returned. This goes beyond the schema's property descriptions.
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 a specific verb ('Compare') and resource ('cryptocurrencies'), and clearly indicates a side-by-side comparison of multiple coins. It also lists the exact metrics shown (price, market cap, 24h volume, 24h performance), which distinguishes it from sibling tools like price (single coin) or market_overview (broad market).
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 implies usage for comparing two or more cryptocurrencies, but it does not explicitly contrast with alternatives or state when not to use it. The phrase 'two or more' hints that it is not for single-coin queries, but no direct references to sibling tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals the data source (CoinGecko), the metric (search volume), the time window (last 24 hours), and the output size (top 10). It does not mention rate limits or whether an API key is required, but given the simple read-only nature and presence of an output schema, this is sufficient.
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 and front-loaded with the core statement. The second sentence adds essential context about the trending metric, and the example prompts are practical without being verbose. Every element earns its place, and there is 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 the simple parameter set and the presence of an output schema, the description is largely complete. It explains what the tool does, how trending is determined, and when to use it. The only gap is the lack of api_key parameter guidance, but that is a minor omission for a tool with one optional parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no explanation of the single api_key parameter, and the schema coverage is 0%. The optional api_key with a default empty string is not described, so the agent cannot infer when or how to provide it. The description should at least note that an API key is optional or required for higher rate limits.
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 function: 'Get the top 10 trending cryptocurrencies on CoinGecko right now.' It specifies the resource (CoinGecko), the action (get), the result limit (top 10), and the temporal scope (right now). It also differentiates from siblings by explicitly stating trending is based on search volume over 24 hours, which distinguishes it from top_coins or price tools.
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 provides clear context for when to use the tool through example prompts like 'What is trending in crypto today?' and 'Show me the hottest coins right now.' It implies usage for trending/search-volume queries, but it does not explicitly exclude alternatives (e.g., top_coins for market cap) or name sibling tools as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![cryptosense-mcp MCP server](https://glama.ai/mcp/servers/josephibra/cryptosense-mcp/badges/card.svg)](https://glama.ai/mcp/servers/josephibra/cryptosense-mcp)

Score Badge

Copy to your README.md:

[![cryptosense-mcp MCP server](https://glama.ai/mcp/servers/josephibra/cryptosense-mcp/badges/score.svg)](https://glama.ai/mcp/servers/josephibra/cryptosense-mcp)

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/josephibra/cryptosense-mcp'

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