Hive Intelligence

Official

by hive-intel

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose focused on retrieving endpoints for specific categories within the Hive Intelligence API. The descriptions explicitly define each category's scope (e.g., DeFi, Market Data, NFTs), leaving no ambiguity about which tool to use for a given data domain. Agents can easily select the appropriate tool based on the category name without confusion.
Naming Consistency5/5
All tool names follow a consistent 'get_*_endpoints' pattern, with the asterisk replaced by the specific category (e.g., get_defi_protocol_endpoints, get_market_and_price_endpoints). This uniform verb_noun structure makes the toolset predictable and easy to navigate, with no deviations in naming conventions.
Tool Count5/5
With 12 tools, the server is well-scoped for its purpose of providing access to a comprehensive cryptocurrency and blockchain data API. Each tool corresponds to a distinct data category (e.g., DeFi, NFTs, Security), ensuring that the count aligns with the breadth of the domain without being excessive or insufficient.
Completeness5/5
The toolset provides complete coverage for the Hive Intelligence API domain, with tools for all major categories (DeFi, Market Data, NFTs, Security, etc.) and supporting tools like call_api_endpoint and get_api_endpoint_schema for schema retrieval and endpoint execution. There are no obvious gaps; agents can access the full API surface through these tools.
Average 3/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 4 community issues answered or closed in the last 6 months
- 10 commits in the last 12 weeks
- Last stable release on August 29, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
This repository includes a glama.json configuration file.
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 provided, so the description carries the full burden of behavioral disclosure. It describes what the tool returns (endpoints in a category) but lacks details on behavior: it doesn't mention if this is a read-only operation, potential rate limits, authentication needs, or the format of the returned data. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly verbose and poorly structured. The first sentence states the purpose clearly, but the rest is a long, repetitive list of endpoint types (e.g., 'TVL data, protocol listings, chain-specific TVL metrics...') that doesn't add value beyond the initial category definition. This wastes space and reduces clarity.
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 the complexity (a tool to retrieve endpoints) and lack of annotations and output schema, the description is incomplete. It explains what the tool does but fails to cover behavioral aspects like response format, error handling, or operational constraints. For a tool with no structured data support, more context is needed to be fully helpful.
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 0 parameters with 100% coverage, so no parameters need documentation. The description doesn't add parameter information, but this is acceptable given the schema's completeness. A baseline of 4 is appropriate as the description doesn't need to compensate for any gaps, and it avoids misleading param details.
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's purpose: 'Get all endpoints in the "DeFi Protocol Analytics" category.' It specifies the verb ('Get') and resource ('endpoints') with a clear category scope. However, it doesn't explicitly differentiate from sibling tools like 'get_token_contract_endpoints' or 'get_onchain_dex_pool_endpoints' beyond the category name, which is why it doesn't reach a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives. It lists the types of endpoints included but doesn't mention sibling tools or specify scenarios where this tool is preferred over others, such as for DeFi-specific analytics versus general market data. This leaves the agent without explicit usage context.
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 describes what data is retrieved but lacks details on how the tool behaves: e.g., whether it returns a list, pagination, rate limits, authentication needs, or error handling. The description is informative about content but misses operational traits, which is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single run-on sentence that lists numerous data types in a dense, unstructured manner. While it front-loads the core purpose ('Get all endpoints...'), the extensive enumeration of examples (e.g., 'stablecoin market analytics', 'perpetual futures funding rates') adds verbosity without clear organization, making it less efficient and harder to parse quickly.
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 the complexity implied by the broad data scope and lack of annotations or output schema, the description is incomplete. It details what data is included but omits critical behavioral aspects (e.g., return format, pagination, errors) and doesn't address how to use the retrieved endpoints. For a tool with no structured support fields, this leaves significant gaps in understanding its practical use.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately adds no parameter details, as there are none to explain. This meets the baseline for a parameterless tool, though it doesn't compensate for any gaps since none exist.
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's purpose: 'Get all endpoints in the "Market Data and Price" category.' It specifies the resource (endpoints) and category scope, though it doesn't explicitly differentiate from siblings like 'get_api_endpoint_schema' or 'get_search_discovery_endpoints' beyond the category name. The detailed list of included data types (e.g., cryptocurrency prices, market caps) adds specificity but doesn't directly contrast with other tools.
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?
The description provides no guidance on when to use this tool versus alternatives. It lists what the tool retrieves but doesn't mention when to choose it over siblings like 'get_api_endpoint_schema' (for schema details) or 'get_search_discovery_endpoints' (for search-related endpoints). There's no explicit context, exclusions, or prerequisites stated, leaving usage decisions unclear.
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 must fully disclose behavioral traits. It states the tool retrieves endpoints but doesn't describe how (e.g., format, pagination, rate limits, authentication needs, or error handling). The list of endpoint types implies breadth but lacks operational details, leaving significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly verbose and poorly structured. It's a single run-on sentence listing numerous endpoint types without prioritization or grouping, making it hard to parse. While it covers many details, the lack of organization and excessive length reduces clarity and efficiency.
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 the complexity implied by the extensive list of endpoint types and the absence of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a list, format, or structure), how to handle the data, or any limitations. For a tool with no structured support, this leaves too many operational questions unanswered.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's scope. Since there are no parameters, the baseline is 4, as the description doesn't need to compensate for any schema gaps.
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's purpose: 'Get all endpoints in the "Network & Infrastructure" category.' It specifies the verb ('Get') and resource ('endpoints'), and provides a comprehensive list of what those endpoints cover, making the purpose unambiguous. However, it doesn't explicitly distinguish this tool from its siblings (e.g., 'get_defi_protocol_endpoints'), which prevents a score of 5.
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?
The description provides no guidance on when to use this tool versus its siblings. It lists many types of endpoints covered but doesn't explain how this differs from tools like 'get_onchain_dex_pool_endpoints' or 'get_market_and_price_endpoints'. There's no mention of prerequisites, alternatives, or exclusions, leaving usage context unclear.
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 full burden. It describes what data is included (e.g., liquidity data, trading pairs, OHLCV) but lacks behavioral details: no mention of permissions needed, rate limits, pagination, error handling, or response format. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly verbose and poorly structured. It starts with a clear purpose but devolves into a run-on list of analytics features (e.g., 'DEXScreener-style metrics', 'options trading analytics') that don't add value beyond the initial category definition. Sentences are not front-loaded with essential information.
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 the tool's complexity (broad analytics scope) and lack of annotations/output schema, the description is incomplete. It catalogs data types but omits critical context: how results are returned, any limitations, or error scenarios. For a tool with rich data potential, this leaves too many unknowns for an agent.
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 0 parameters, and schema description coverage is 100% (empty schema). With no parameters to document, the baseline is 4. The description doesn't need to compensate for any parameter gaps, so it meets expectations.
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's purpose: 'Get all endpoints in the "On-Chain DEX & Pool Analytics" category.' It specifies the resource (endpoints) and category scope, distinguishing it from siblings like 'get_defi_protocol_endpoints' or 'get_market_and_price_endpoints'. However, it doesn't explicitly contrast with all siblings, so it's not a perfect 5.
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?
The description provides no guidance on when to use this tool versus alternatives. It lists many analytics capabilities but doesn't specify prerequisites, exclusions, or compare to sibling tools like 'get_defi_protocol_endpoints' for similar data. Usage is implied by the category name only.
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. It mentions the tool 'Get all endpoints', implying a read-only operation, but does not disclose behavioral traits such as rate limits, authentication needs, or what the output format looks like. The list of functionalities (e.g., 'real-time balance tracking') describes the endpoints' purposes, not the tool's behavior, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly verbose and lacks front-loading. The first sentence states the purpose, but the rest is a long, unstructured list of endpoint functionalities (e.g., 'comprehensive wallet activity monitoring', 'financial auditing capabilities') that does not earn its place by adding value beyond the initial statement. This reduces clarity and efficiency.
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 the complexity of endpoints and lack of annotations or output schema, the description is incomplete. It lists what the endpoints do but fails to explain the tool's behavior, return values, or usage context. For a tool that retrieves a category of endpoints, more details on output format or integration with siblings would be necessary for adequate 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 input schema has 0 parameters with 100% coverage, so no parameter information is needed. The description appropriately does not discuss parameters, focusing instead on the tool's purpose and the endpoints' functionalities. This aligns with the baseline of 4 for tools with no parameters, as it adds context without redundancy.
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's purpose: 'Get all endpoints in the "Portfolio & Wallet" category.' It specifies the verb ('Get') and resource ('endpoints'), and distinguishes the category from siblings like 'get_defi_protocol_endpoints' or 'get_nft_analytics_endpoints'. However, it does not explicitly differentiate from all siblings, such as 'get_api_endpoint_schema', which might be related but serves a different function.
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?
The description provides no guidance on when to use this tool versus alternatives. It lists functionalities like 'tracking user wallet balances' and 'transaction history', but does not specify prerequisites, exclusions, or compare it to sibling tools. For example, it does not clarify if this is for listing endpoints versus calling them, unlike 'call_api_endpoint'.
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 describes what the endpoints cover (e.g., token metadata, transaction analysis) but doesn't mention operational traits like rate limits, authentication needs, pagination, or error handling. For a tool with zero annotation coverage, this leaves significant gaps in understanding how to interact with it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly verbose and poorly structured. It starts with a clear purpose but then devolves into a long, comma-separated list of endpoint capabilities (e.g., 'token metadata, holder distributions...'). This information could be condensed or omitted, as it doesn't directly help the agent invoke the tool. The lack of front-loading and excessive detail reduces clarity.
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 the complexity implied by the extensive endpoint list and lack of annotations or output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a list of endpoint names, full configurations) or how to handle the data. For a tool with no structured output information, more guidance on expected behavior is needed.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, which aligns with the schema. A baseline of 4 is applied since the description doesn't need to compensate for any parameter gaps.
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's purpose: 'Get all endpoints in the "Token & Contract data" category.' It specifies the verb ('Get') and resource ('endpoints'), and the category name distinguishes it from sibling tools like 'get_defi_protocol_endpoints' or 'get_nft_analytics_endpoints'. However, it doesn't explicitly differentiate beyond the category name, which is why it's a 4 rather than a 5.
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?
The description provides no guidance on when to use this tool versus alternatives. It lists what the endpoints cover but doesn't mention prerequisites, exclusions, or compare it to sibling tools like 'get_api_endpoint_schema' or 'call_api_endpoint'. Without this context, the agent must infer usage from the category name alone.
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 full burden. It implies a read operation ('Get') but doesn't disclose behavioral traits such as authentication needs, rate limits, pagination, or response format. The list of security topics adds context but not operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose but becomes verbose with a lengthy list of security topics. Sentences like 'Comprehensive security endpoints for token security analysis...' could be condensed or structured as bullet points for better clarity.
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 no annotations and no output schema, the description is incomplete. It lacks details on what the tool returns (e.g., endpoint list format, metadata) and operational constraints, which are critical for an agent to use it effectively.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately omits parameter details, maintaining focus on the tool's purpose without redundancy.
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's purpose: 'Get all endpoints in the "Security & Risk Analysis" category.' It specifies the verb ('Get') and resource ('endpoints'), and distinguishes from siblings by focusing on security endpoints. However, it could be more specific about what 'get' entails (e.g., list, retrieve details).
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?
The description provides no explicit guidance on when to use this tool versus alternatives. It mentions the category but doesn't compare to sibling tools like 'get_token_contract_endpoints' or 'get_nft_analytics_endpoints', leaving the agent to infer usage based on category alone.
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 describes what endpoints are included (e.g., social media analytics, sentiment analysis) but does not mention critical behaviors such as whether this is a read-only operation, if it requires authentication, rate limits, or what the output format looks like. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, but it becomes verbose with a long list of examples (e.g., 'Galaxy Score™, AltRank™') that could be condensed. While informative, some sentences do not earn their place by adding critical value beyond the initial scope, reducing efficiency.
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 the complexity (a tool retrieving endpoints with no output schema and no annotations), the description is incomplete. It details the category content but fails to explain the return format, pagination, error handling, or other behavioral aspects. Without annotations or an output schema, the description should provide more context to be fully helpful.
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 0 parameters with 100% coverage, so the schema fully documents the lack of inputs. The description does not add parameter information, which is unnecessary here. Since there are no parameters, the baseline score is 4, as the description does not need to compensate for any schema gaps.
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's purpose: 'Get all endpoints in the "Social Media & Sentiment Analytics" category.' It specifies the resource (endpoints) and the category scope. However, it does not explicitly distinguish this tool from its siblings (e.g., get_defi_protocol_endpoints, get_market_and_price_endpoints), which all follow a similar 'get [category] endpoints' pattern, so it lacks sibling differentiation.
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?
The description provides no guidance on when to use this tool versus alternatives. It lists the types of endpoints included but does not mention prerequisites, exclusions, or comparisons to other tools (e.g., when to use get_search_discovery_endpoints instead). This leaves the agent without explicit usage instructions.
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. It describes what the endpoints cover but lacks behavioral details: it doesn't specify if this is a read-only operation, potential rate limits, authentication needs, response format, or pagination. The description is informative about scope but misses key operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose but becomes overly verbose with a long list of features. Sentences like 'Endpoints for comprehensive NFT ecosystem analysis...' could be more concise. While informative, the list of examples (e.g., 'collection floor prices, trading volumes') adds bulk without critical guidance, reducing efficiency.
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?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is moderately complete. It explains the category and examples well but lacks behavioral context and usage guidelines. For a no-param tool, this is adequate but has clear gaps in transparency and sibling differentiation.
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 0 parameters, and schema description coverage is 100%. The description doesn't need to explain parameters, and it appropriately focuses on the tool's function. A baseline of 4 is applied since no parameters exist, and the description adds value by detailing the category scope without redundancy.
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's purpose: 'Get all endpoints in the "NFT Analytics" category.' It specifies the verb ('Get') and resource ('endpoints'), and distinguishes the category ('NFT Analytics'). However, it doesn't explicitly differentiate from sibling tools like 'get_search_discovery_endpoints' or 'get_social_sentiment_endpoints' that might overlap, preventing a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives. It lists many features covered by the endpoints but doesn't mention sibling tools or contexts where other tools might be more appropriate. For example, it doesn't clarify if this should be used instead of 'get_social_sentiment_endpoints' for NFT-related sentiment.
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 tool 'Get all endpoints' but does not clarify if this is a read-only operation, if it requires authentication, what the return format is (e.g., list, JSON), or any rate limits. The description lists examples of endpoint types but lacks operational details, making it insufficient for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose but becomes verbose with a long list of examples (e.g., 'cryptocurrency search functionality, trending analysis...'). While these examples add context, they could be more streamlined. The structure is adequate but not optimally concise, as some sentences could be condensed without losing meaning.
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?
Given the tool's complexity (simple retrieval with no parameters) and lack of annotations and output schema, the description is moderately complete. It explains what the tool returns (endpoints in a specific category with examples) but misses key behavioral aspects like response format or operational constraints. For a zero-parameter tool, it provides enough context to understand the scope but not full operational guidance.
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 0 parameters, and the input schema has 100% description coverage (though empty). The description does not need to add parameter details, so it appropriately focuses on the tool's purpose. Since there are no parameters, a baseline score of 4 is applied, as the description compensates by explaining what the tool does without unnecessary parameter information.
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's purpose: 'Get all endpoints in the "Search & Discovery" category.' It specifies the verb ('Get') and resource ('endpoints'), and the following list provides concrete examples of what these endpoints cover (e.g., cryptocurrency search, trending analysis). However, it does not explicitly differentiate from sibling tools like 'get_api_endpoint_schema' or 'call_api_endpoint', which slightly limits its clarity in context.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools or contexts where this tool is preferred, such as for retrieving endpoints related to search and discovery versus other categories like 'get_market_and_price_endpoints'. This lack of comparative guidance leaves the agent without explicit usage instructions.
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 mentions that the tool calls an API endpoint but lacks details on authentication requirements, rate limits, error handling, or what the response entails. For a tool that performs API calls with potential side effects, this is a significant gap in 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 highly concise and front-loaded, consisting of two sentences that directly address the tool's purpose and usage guidelines. There is no wasted text, and every sentence contributes essential information, making it efficient and well-structured.
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 the complexity of calling arbitrary API endpoints, the lack of annotations, and no output schema, the description is insufficient. It doesn't cover behavioral aspects like authentication, error handling, or response format, leaving critical gaps for an agent to use the tool effectively in a real-world context.
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 schema description coverage is 100%, with both parameters ('endpoint_name' and 'args') well-documented in the input schema. The description adds minimal value by referencing the 'get_api_endpoint_schema' tool for schema matching, but it doesn't provide additional semantic context beyond what the schema already states. This meets the baseline for high schema coverage.
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's purpose: 'call an endpoint in the HIVE API.' It specifies the verb ('call') and resource ('endpoint in the HIVE API'), making the action explicit. However, it doesn't distinguish this from sibling tools that also interact with endpoints (like 'get_api_endpoint_schema'), which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: it instructs to first use 'category endpoints' to list endpoints and then 'get_api_endpoint_schema' to obtain the schema before calling this tool. This sets clear prerequisites and distinguishes it from alternatives by outlining a workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 describes the tool's function (retrieving schemas) and its relationship to another tool (call_api_endpoint), which adds useful context. However, it doesn't mention potential behavioral traits like error conditions (e.g., what happens if the endpoint doesn't exist), rate limits, authentication requirements, or the format/structure of the returned schema. For a tool with zero annotation coverage, this leaves gaps in understanding its operational behavior.
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 that are front-loaded with the core purpose and immediately followed by practical usage guidance. Every word earns its place—there's no redundancy, fluff, or unnecessary elaboration. It efficiently communicates both what the tool does and how it fits into the larger workflow.
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?
Given the tool's low complexity (1 parameter, no nested objects, no output schema) and the absence of annotations, the description is moderately complete. It covers the purpose and usage context well, but lacks details on behavioral aspects (e.g., error handling, schema format) and doesn't clarify differentiation from sibling tools. For a simple read operation, this is adequate but not fully comprehensive, especially without annotations to fill in 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 has 100% description coverage, with the single parameter 'endpoint' clearly documented as 'The name of the endpoint to get the schema for.' The description doesn't add any additional semantic information about this parameter beyond what the schema provides (e.g., examples of endpoint names, format constraints). According to the rules, when schema_description_coverage is high (>80%), the baseline score is 3 even with no param info in the description, which applies here.
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 ('Get') and resource ('schema for an endpoint in the HIVE API'), making the purpose specific and understandable. However, it doesn't explicitly differentiate this tool from its many siblings (like get_defi_protocol_endpoints, get_token_contract_endpoints, etc.), which all seem to retrieve endpoint-related schemas but for different categories. A perfect score would require clarifying how this general endpoint schema tool differs from those category-specific ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'You can use the schema returned by this tool to call an endpoint with the `call_api_endpoint` tool.' This directly states the tool's purpose in the workflow and names the alternative/complementary tool (call_api_endpoint), giving clear context for usage without any misleading information.
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:

[![hive-sdk MCP server](https://glama.ai/mcp/servers/hive-intel/hive-sdk/badges/card.svg)](https://glama.ai/mcp/servers/hive-intel/hive-sdk)

Score Badge

Copy to your README.md:

[![hive-sdk MCP server](https://glama.ai/mcp/servers/hive-intel/hive-sdk/badges/score.svg)](https://glama.ai/mcp/servers/hive-intel/hive-sdk)

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/hive-intel/hive-sdk'

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