hive-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
The Jira and Sourcegraph tools are cleanly separated by prefix and purpose. Each Jira tool targets a distinct resource (issue, comments, attachments), and the two Sourcegraph tools are clearly differentiated by search mode.
Naming Consistency5/5
All tool names follow a consistent snake_case pattern with a service prefix (jira_ or sourcegraph_) followed by a clear verb_noun structure (e.g., get_issue, add_comment, search_code). No mixed conventions.
Tool Count4/5
The 7-tool count is within the ideal range, but the server spans two distinct domains (Jira and Sourcegraph), which slightly dilutes focus. Still, each tool earns its place for basic workflows.
Completeness3/5
The Jira coverage lacks core operations like create_issue, update_issue, or delete_issue, limiting workflow completion. Sourcegraph only offers search and deep search, with no direct file retrieval or repository browsing, leaving notable gaps for a development tool.
Average 3.9/5 across 7 of 7 tools scored. Lowest: 3.1/5.
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 provided, so the description carries the full burden for behavioral disclosure. It only states that it searches code and supports operators, but does not disclose potential side effects, rate limits, authentication requirements, or limitations such as result caps or default patterns.
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, two sentences long, and front-loaded with the primary purpose. There is no filler or redundant content.
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?
For a single-parameter tool with a rich schema, the description covers the core purpose and operator support. However, it lacks behavioral context (e.g., limitations) and does not guide the user toward or away from the sibling tool, making it incomplete for a tool in a contextual set.
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 for the query parameter is very detailed, listing operators and examples. The tool description adds only a general mention of operators, which does not exceed what the schema already provides. With 100% schema coverage, the baseline of 3 is appropriate.
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 function: 'Search code across repositories using Sourcegraph.' This is a specific verb and resource. However, it does not distinguish it from the sibling tool sourcegraph_deep_search, so it doesn't fully differentiate.
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?
There is no guidance on when to use this tool versus the sibling sourcegraph_deep_search. The description mentions supported operators but does not provide context for selecting this tool over alternatives, such as when a deep search is needed.
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 must disclose behavioral expectations. It only states the action without mentioning permissions, whether it appends to existing comments, what response to expect, or any side effects, leaving a significant transparency gap.
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, concise sentence that gets straight to the point with no redundant or unnecessary information.
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 relatively simple with two well-documented parameters, but the lack of annotations and output schema means the description should provide more context about behavior and return values. It is minimally adequate for a simple add-comment operation without being fully comprehensive.
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% coverage with clear descriptions for both parameters (comment text and issue key/ID). The description adds no additional parameter context beyond what the schema already provides, meeting the baseline for high schema coverage.
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 ('Add') and resource ('comment to a Jira issue'), clearly distinguishing it from sibling tools like jira_get_comments which retrieves comments, and jira_get_issue which fetches issue details.
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 clearly states the tool's purpose, making its primary use case obvious. However, it does not explicitly mention when to avoid this tool or use an alternative, relying on the sibling tool names to imply differentiation.
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 must carry the full burden. It discloses that it uses Sourcegraph's agentic search (REST API v6.7+) and may take 10-60 seconds, which is useful. However, it does not explicitly state that it is a read-only operation or describe any side effects, which is a gap for a tool with no 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first gives the primary purpose with examples, the second adds key technical details about the underlying API and latency. It is front-loaded, concise, and every sentence adds value without fluff.
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 has no output schema, so the description should explain what the tool returns. It does not describe the output format or content of the answer. It covers the key operational context (time, API) but misses return value expectations and any caveats about scope or limitations.
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, so the baseline is 3. The description reinforces the question parameter with examples, but it does not add new meaning beyond what the schema already provides. The timeout_seconds parameter is not mentioned in the description but is fully covered by the schema.
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 this is an AI-powered deep search for natural language questions about a codebase, with concrete examples. It distinguishes itself from sibling sourcegraph_search_code by emphasizing natural language and agentic search, and from other Jira tools which are unrelated.
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 usage context by giving example questions and noting it may take 10-60 seconds. However, it does not explicitly mention when to use sourcegraph_search_code instead of this tool, though the natural language focus implies it for conversational queries.
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?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It does explain that the tool returns authors, timestamps, and content, and hints at potentially large responses via pagination advice. However, it does not disclose sorting order, error behavior, or permission requirements, which would be helpful for a full understanding.
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 three concise sentences, each with a clear purpose: stating the primary function, describing the returned data, and offering usage guidance. There is no fluff or redundancy, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with no output schema, the description adequately covers the purpose, return content, and pagination support. It lacks specifics about pagination response structure (e.g., total count) but overall provides enough context for an agent to understand and use the tool correctly.
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 only adds a general note that pagination parameters control response size, reinforcing what the schema already states. It does not provide additional meaning or context beyond the parameter 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 begins with 'Get comments from a Jira issue', clearly specifying the action and resource. It distinguishes from sibling tools like jira_add_comment (write) and jira_get_issue (issue details) by focusing on reading comment history. Also mentions pagination support and return contents.
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 purpose makes clear when to use this tool: when needing comment history for an issue. It also advises using pagination parameters to control response size and avoid token limits, which is practical guidance. However, it doesn't explicitly state when not to use it or compare with alternatives like jira_add_comment.
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?
No annotations are provided, so the description carries full responsibility. It discloses that the tool returns metadata (IDs, filenames, sizes, mime types) and implicitly indicates it is a read-only list operation. It does not mention edge cases like pagination or empty results, but for a simple listing tool 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?
Two concise sentences with no wasted words. The first sentence states the core purpose, and the second clarifies the return value, making it optimally front-loaded.
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?
This is a low-complexity tool with a single parameter and no output schema. The description adequately covers the tool's purpose and return value, though it could mention potential limitations (e.g., whether attachments are paginated) to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single parameter (issueKey) with an example format. The description adds no additional parameter semantics, so the baseline score of 3 applies.
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 ('List') and identifies the exact resource ('attachments for a Jira issue'), clearly distinguishing it from sibling tools like jira_read_attachment (which implies reading content) and jira_get_comments. It also names the output type (metadata) and key fields.
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 (to list attachments and get their metadata) but provides no explicit guidance on when to prefer this over jira_read_attachment or other siblings. It does not state exclusions or alternatives, though the verb 'List' helps infer scope.
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 provided, the description carries the full burden. It discloses non-obvious behaviors: images return as blob, other files as base64, and files over 500KB return only metadata. This gives the agent clear expectations about output variations, though it omits error handling and authentication requirements.
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 three concise sentences, front-loaded with the purpose. Every sentence contributes: purpose, return format, and size threshold. No filler or redundant 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?
For a simple one-parameter read tool with no output schema, the description covers the essential aspects: action, return format, and size limit. It lacks explicit error-case handling, but the tool is simple enough that the description is sufficiently complete for an agent to select and invoke it correctly.
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 already provides a description for attachmentId with an example, achieving 100% coverage. The description's 'by ID' adds no new semantic meaning beyond the schema, so it stays at the baseline for high schema coverage.
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 opens with a specific verb and resource: 'Read a specific Jira attachment by ID.' This clearly identifies the action and target. It also distinguishes itself from sibling jira_list_attachments by focusing on reading a single attachment's content rather than listing.
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 when an attachment ID is known and content is needed, but it does not explicitly contrast with alternatives like jira_list_attachments or state when not to use this tool. The size-limit note provides some contextual boundary, but not a direct usage guide.
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 burden of behavioral disclosure. It reveals that the default response includes a minimal set of fields to avoid token limits, which is a significant behavioral trait. However, it does not mention error handling, authentication, or response shape beyond field listings, leaving some gaps.
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 three sentences, front-loading the core purpose and then providing essential usage tips. Every sentence contributes value: the first identifies the resource, the second and third explain parameter usage and default behavior. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with only two parameters and no output schema, the description plus schema cover the essential aspects: how to identify the issue, what default fields are returned, how to customize fields, and which sibling tools to use for related operations. Error handling and auth are not explicitly covered, but these are commonly inferred and not critical for a basic retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% since both parameters have detailed descriptions in the schema. The description adds a note about using 'fields' to control response size, but this duplicates information already present in the schema description. With high schema coverage, the baseline of 3 is appropriate; the description does not enrich parameter semantics beyond what the schema provides.
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 'Get detailed information about a Jira issue by its key or ID', which is a specific verb+resource combination. The tool's purpose is unambiguous and inherently distinct from sibling tools like jira_get_comments and jira_list_attachments, especially since the schema explicitly mentions these alternatives.
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 schema explicitly directs users to jira_get_comments for comments and jira_list_attachments for attachments, providing clear alternative tool guidance. Additionally, the description advises using the fields parameter to control response size and indicates when to add fields ('Only specify fields if you need additional information'), effectively stating when to use this tool's features versus defaults.
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-mcp MCP server](https://glama.ai/mcp/servers/Ocuco/hive-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Ocuco/hive-mcp)

Score Badge

Copy to your README.md:

[![hive-mcp MCP server](https://glama.ai/mcp/servers/Ocuco/hive-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Ocuco/hive-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/Ocuco/hive-mcp'

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