TheHive FastMCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct entity (alert, case, task, observable) and action (create, get, search, add). There is no overlap in functionality; for instance, create_alert and create_case are clearly different, and get_alert vs get_case are unambiguously separate.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case (e.g., create_alert, get_case, search_cases). There are no deviations, mixed conventions, or ambiguous verbs.
Tool Count5/5
With 11 tools, the server covers the essential operations for TheHive (alerts, cases, tasks, observables). The count is balanced—neither too few to be useless nor too many to be overwhelming.
Completeness3/5
The server provides create, get, and search operations for alerts and cases, but lacks update and delete operations for both. Additionally, there is no tool to promote an alert to a case or to close/merge cases. These gaps are notable for full lifecycle management.
Average 3.7/5 across 11 of 11 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
With no annotations, the description must disclose behavioral traits. It only explains the parameter format but does not state that the tool is read-only or mention any authentication or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured with a clear purpose followed by parameter documentation. No unnecessary words, though it could be slightly more organized.
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 an output schema exists, return values are covered. However, the description lacks error handling information or differentiation from sibling tools, which would improve 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?
Schema description coverage is 0%, so the description adds essential meaning by explaining that `id_or_name` is a unique ID starting with '~' or a case number. This compensates for the lack of schema documentation.
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 that it retrieves detailed information about a specific case by ID or case number. However, it does not explicitly differentiate from sibling tools like `search_cases`, which returns multiple cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it does not mention that this is for a single case while `search_cases` is for searching multiple.
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 the full burden. It does not disclose behavioral traits like side effects, idempotency, permissions required, or return value. While an output schema exists, the description does not reference it or explain what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a single front-loaded sentence followed by a clean parameter list. Every line adds value, though a more structured format with separate sections could improve scannability.
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 has 5 parameters, no annotations, and an output schema, the description covers purpose and parameters but misses usage context and behavioral details. It is adequate but not fully complete for an agent to confidently use without additional information.
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?
With 0% schema description coverage, the description compensates by listing each parameter with a brief explanation (e.g., 'assignee: Login/email of the user assigned'). However, it lacks examples, constraints, or detailed format guidance, providing only minimal added value over 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 the tool creates a new Task inside an existing Case for tracking investigation steps. It uses a specific verb-resource-context combination that distinguishes it from sibling tools like create_case or create_alert.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as add_task_log or get_case_tasks. Prerequisites (e.g., case existence) are not mentioned, and no exclusions or when-not-to-use scenarios are given.
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 bears full responsibility. It fails to disclose side effects, idempotency, success behavior, or error cases. The description only explains parameters without behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear opening sentence followed by a structured parameter list. Each parameter has a brief explanation. Slightly redundant formatting (e.g., 'Args:' block) could be tighter, but overall efficient.
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 7 parameters and an output schema, the description covers parameter semantics well but lacks behavioral and usage guidance. It does not mention return format, required parameter order, or edge cases, leaving the tool partially underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage (no property descriptions), but the description adds comprehensive meaning: it explains all parameters, including default values and enumerated levels (severity, TLP, PAP). This provides critical context beyond the raw 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 the tool creates a new security incident case in TheHive, using a specific verb and resource. It distinguishes from siblings like create_alert or create_task by specifying 'case' as the target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., create_alert, create_task). There is no mention of prerequisites, context, or conditions for use.
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 carries full burden. It indicates a read operation with 'Get', but does not add behavioral details like permissions or output structure beyond what the output schema provides. Adequate but minimal.
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 extremely concise, with every sentence serving a purpose. It uses a clear docstring format and is front-loaded with the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and an output schema, the description covers the basic purpose. However, it lacks context on when to use this tool vs. search_alerts or prerequisites. Adequate for a simple tool but could be more complete.
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?
Schema description coverage is 0%, and the description only repeats the parameter name and type ('The unique ID of the alert'), which is already clear from the schema title. It adds no significant meaning beyond 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 the tool gets detailed information about a specific alert by ID, using a specific verb and resource. It distinguishes from siblings like create_alert and search_alerts.
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 you have an alert ID, but does not explicitly state when to use versus alternatives like search_alerts. No when-not-to guidance provided.
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, the description carries full burden. It describes parameter behavior (e.g., tags require all matches) but lacks details on pagination, maximum limit, authentication needs, or error handling. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description starts with a clear one-line purpose, followed by a well-structured bullet list for parameters. While the list is long, each parameter has a brief but informative explanation. No unnecessary 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 description covers all parameters adequately but lacks contextual information such as pagination behavior, result handling (empty list vs null), and any constraints on the limit parameter. Given the presence of an output schema, return values need not be detailed, but behavioral completeness is moderate.
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 0%, so the description compensates well. It explains the meaning of each parameter beyond schema type/defaults: substring match for title, exact level for severity, AND logic for tags, examples for status, sorting syntax with '-' prefix, and date formats. Missing details on tags being a list of strings (but schema provides that).
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 'Search for Alerts in TheHive with advanced filtering', which is a specific verb-resource combination. It distinguishes from siblings like get_alert (single alert retrieval) and search_cases (cases vs alerts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_alert or search_cases. The description only explains what the tool does, not the context for choosing it.
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 lists parameters but does not disclose behavioral traits such as side effects (e.g., whether the alert triggers case creation), required permissions, error handling for duplicate source_ref, or idempotency. The description focuses on parameter details, not behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized given the lack of schema descriptions. It front-loads the main purpose and then lists parameters in a structured, readable manner. While a bit lengthy, every sentence earns its place. Could be more concise if schema were richer.
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 9 parameters with moderate complexity and an output schema (not shown in context). The description thoroughly documents all parameters but lacks broader context like what happens after creation, how the alert integrates with TheHive workflows, or expected return values. Given the output schema existence, the lack of return value explanation is acceptable, but missing behavioral context reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides comprehensive detail for all 9 parameters: types, examples, default values, and optionality. For example, it explains severity levels (1-4) and gives example values for source. This adds significant meaning beyond the bare 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 'Create a new Alert in TheHive' with a specific verb and resource. It also distinguishes alerts from cases via context ('Alerts represent potential incidents fetched from SIEMs, emails, etc.'), which helps differentiate it from sibling tools like create_case.
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 external incident data (e.g., SIEM, emails), but does not explicitly state when to use this tool versus alternatives like create_case or search_alerts. No exclusions or prerequisite conditions 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 full burden for behavioral traits. It does not disclose any side effects, auth requirements, rate limits, or safety information. It only describes parameter semantics. For a search tool, it omits details like pagination or maximum result behavior beyond the limit parameter.
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 verbose, listing all 8 parameters in a docstring format. It is front-loaded with the purpose sentence, but the parameter list is lengthy. While every sentence provides value, it could be more concise by grouping or omitting trivial details. The structure is clear but not optimally compact.
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 has 8 parameters, no annotations, and an output schema exists, the description covers input well but lacks overall context. It does not mention that it returns a list of cases, or any performance considerations. The output schema likely covers return values, so this is acceptable, but some additional guidance (e.g., default limit of 10) is included.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no parameter descriptions. The tool description fully compensates by explaining each parameter: title as substring match, severity as exact, tags as all must match, sort with prefix for descending, dates ISO 8601 or ms timestamp. This adds significant meaning beyond the schema property names.
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 'Search for Cases in TheHive with advanced filtering capabilities.' This distinguishes it from siblings like get_case (retrieves a single case) and create_case (creates). The verb 'search' and resource 'Cases' are specific, and the parameters further clarify the functionality.
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 detailed parameter explanations (e.g., sort with '-‘ prefix for descending, tags require all to match). It gives implicit guidance on how to use filters. However, it does not explicitly state when to use this tool versus alternatives, such as 'Use get_case for a specific case without filters.' Given sibling context, it is still clear.
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?
Without annotations, the description carries full burden. It discloses the tool is a write operation and mentions that message supports markdown, but does not describe error handling, side effects, or required task state. This is adequate but not comprehensive.
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 very concise: two sentences plus an Args list. The main purpose is front-loaded, and every sentence adds value 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?
While the tool has an output schema (relieving need to describe return values), the description omits prerequisites (e.g., task must exist), error conditions, or any behavioral nuances. Given no annotations, more context would improve 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?
Schema description coverage is 0%, yet the description provides clear explanations for both parameters: task_id is the unique ID, message is a log note with markdown support. This adds significant meaning beyond the schema titles.
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 and resource: 'Add a progress log entry (log note) to an existing Task.' It clearly distinguishes from sibling tools like create_task or get_case_tasks, which deal with tasks themselves.
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 you want to add a log to an existing task, but does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusions or context on prerequisites.
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 behavior. It only states what the tool does without revealing side effects, prerequisites (e.g., case existence), permissions, or idempotence. This is insufficient for a mutation tool.
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 well-structured as a docstring with a clear main sentence and an Args section. Every sentence adds value, no redundancy, and the critical info 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?
Given the existence of an output schema, the description adequately covers the tool's purpose and parameters. It could hint at prerequisites (e.g., case must exist), but it's mostly complete for an observable creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description carries the full burden and does so excellently. Every parameter is described with its purpose, acceptable values (e.g., data_type examples, tlp range), and defaults, providing rich context beyond 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 the tool adds an Observable (IoC) to an existing Case, specifying the action and resource. This distinguishes it from siblings like create_case or get_case_observables.
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 (adding an observable to an existing case), but there is no explicit guidance on when not to use it or mention of alternatives like create_case when the case doesn't exist.
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?
Describes sorting, date filtering, and default limit. No annotations exist, so description carries full burden. Could mention non-destructive nature, but overall adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Structured list of parameters, front-loaded with purpose. Slightly verbose with 'Args:' but overall clear and efficient.
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?
Covers all 5 parameters for a list tool with output schema. Minor inconsistency: 'List all' vs 'Maximum number'. Adequate for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so description fully explains each parameter: case_id as unique ID, sort with '-' prefix, date filters as ISO 8601/timestamps, limit with default 50.
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?
Clearly states 'List all observables associated with a specific Case' with a specific verb and resource. Distinct from sibling tools like get_case or get_case_tasks.
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?
Implies usage for retrieving observables for a case but lacks explicit when-to-use vs alternatives like search_cases or get_case. No exclusions or when-not guidance.
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?
The description discloses that it lists tasks with optional filters, and mentions a default limit. Since no annotations exist, the description adequately conveys a read-only behavior, though it doesn't explicitly state non-destructiveness or auth needs.
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 well-structured as a docstring with a clear main sentence followed by parameter explanations. Every sentence serves a purpose without redundancy, being both concise and informative.
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 5 parameters, 1 required, and an existing output schema, the description thoroughly explains all inputs. It lacks error handling or edge case behavior but adequately covers the core functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), so the description fully compensates by explaining each parameter: case_id, sort (with formatting), date filters (ISO 8601 or timestamp), and limit (default 50). This adds significant meaning beyond bare 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 'List all tasks associated with a specific Case,' specifying the verb and resource. It distinguishes from sibling tools like create_task or get_case, which have different purposes.
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 implicitly indicates when to use (to list tasks for a case) but does not explicitly mention when not to use or compare with alternatives. It provides clear context without exclusions.
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:

[![thehive-fastmcp MCP server](https://glama.ai/mcp/servers/Hoopshaker/thehive-fastmcp/badges/card.svg)](https://glama.ai/mcp/servers/Hoopshaker/thehive-fastmcp)

Score Badge

Copy to your README.md:

[![thehive-fastmcp MCP server](https://glama.ai/mcp/servers/Hoopshaker/thehive-fastmcp/badges/score.svg)](https://glama.ai/mcp/servers/Hoopshaker/thehive-fastmcp)

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/Hoopshaker/thehive-fastmcp'

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