F
licenseNot graded
qualityD
maintenanceA Model Context Protocol (MCP) server that integrates with the MISP (Malware Information Sharing Platform) to provide threat intelligence capabilities to Large Language Models.
12
-
OpenCTI MCP Server
by zxzinn
The OpenCTI MCP Server integrates with the OpenCTI platform to provide a standardized interface for querying and retrieving threat intelligence data.
Key Capabilities:
Threat Intelligence Data
Retrieve latest reports or get specific reports by ID
Search for indicators of compromise, malware, and threat actors
User and Group Management
List all users and groups with their members
Retrieve user details by ID
STIX Object Operations
List attack patterns
Get campaign information by name
System Management
List connectors and status templates
File Operations
List all files or get file details by ID
Reference Data Access
List marking definitions and labels
Customization
Customizable query limits
Full GraphQL query support
Supports full GraphQL query capabilities for interacting with the OpenCTI platform's threat intelligence data.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@OpenCTI MCP Serversearch for recent ransomware reports"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
OpenCTI MCP Server
Overview
OpenCTI MCP Server is a Model Context Protocol (MCP) server that provides seamless integration with OpenCTI (Open Cyber Threat Intelligence) platform. It enables querying and retrieving threat intelligence data through a standardized interface.
Related MCP server: MCP Boilerplate
Features
Fetch and search threat intelligence data
Get latest reports and search by ID
Search for malware information
Query indicators of compromise
Search for threat actors
User and group management
List all users and groups
Get user details by ID
STIX object operations
List attack patterns
Get campaign information by name
System management
List connectors
View status templates
File operations
List all files
Get file details by ID
Reference data access
List marking definitions
View available labels
Customizable query limits
Full GraphQL query support
Prerequisites
Node.js 16 or higher
Access to an OpenCTI instance
OpenCTI API token
Installation
Installing via Smithery
To install OpenCTI Server for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install opencti-server --client claudeManual Installation
# Clone the repository
git clone https://github.com/yourusername/opencti-mcp-server.git
# Install dependencies
cd opencti-mcp-server
npm install
# Build the project
npm run buildConfiguration
Environment Variables
Copy .env.example to .env and update with your OpenCTI credentials:
cp .env.example .envRequired environment variables:
OPENCTI_URL: Your OpenCTI instance URLOPENCTI_TOKEN: Your OpenCTI API token
MCP Settings
Create a configuration file in your MCP settings location:
{
"mcpServers": {
"opencti": {
"command": "node",
"args": ["path/to/opencti-server/build/index.js"],
"env": {
"OPENCTI_URL": "${OPENCTI_URL}", // Will be loaded from .env
"OPENCTI_TOKEN": "${OPENCTI_TOKEN}" // Will be loaded from .env
}
}
}
}Security Notes
Never commit
.envfile or API tokens to version controlKeep your OpenCTI credentials secure
The
.gitignorefile is configured to exclude sensitive files
Available Tools
Available Tools
Reports
get_latest_reports
Retrieves the most recent threat intelligence reports.
{
"name": "get_latest_reports",
"arguments": {
"first": 10 // Optional, defaults to 10
}
}get_report_by_id
Retrieves a specific report by its ID.
{
"name": "get_report_by_id",
"arguments": {
"id": "report-uuid" // Required
}
}Search Operations
search_malware
Searches for malware information in the OpenCTI database.
{
"name": "search_malware",
"arguments": {
"query": "ransomware",
"first": 10 // Optional, defaults to 10
}
}search_indicators
Searches for indicators of compromise.
{
"name": "search_indicators",
"arguments": {
"query": "domain",
"first": 10 // Optional, defaults to 10
}
}search_threat_actors
Searches for threat actor information.
{
"name": "search_threat_actors",
"arguments": {
"query": "APT",
"first": 10 // Optional, defaults to 10
}
}User Management
get_user_by_id
Retrieves user information by ID.
{
"name": "get_user_by_id",
"arguments": {
"id": "user-uuid" // Required
}
}list_users
Lists all users in the system.
{
"name": "list_users",
"arguments": {}
}list_groups
Lists all groups with their members.
{
"name": "list_groups",
"arguments": {
"first": 10 // Optional, defaults to 10
}
}STIX Objects
list_attack_patterns
Lists all attack patterns in the system.
{
"name": "list_attack_patterns",
"arguments": {
"first": 10 // Optional, defaults to 10
}
}get_campaign_by_name
Retrieves campaign information by name.
{
"name": "get_campaign_by_name",
"arguments": {
"name": "campaign-name" // Required
}
}System Management
list_connectors
Lists all system connectors.
{
"name": "list_connectors",
"arguments": {}
}list_status_templates
Lists all status templates.
{
"name": "list_status_templates",
"arguments": {}
}File Operations
get_file_by_id
Retrieves file information by ID.
{
"name": "get_file_by_id",
"arguments": {
"id": "file-uuid" // Required
}
}list_files
Lists all files in the system.
{
"name": "list_files",
"arguments": {}
}Reference Data
list_marking_definitions
Lists all marking definitions.
{
"name": "list_marking_definitions",
"arguments": {}
}list_labels
Lists all available labels.
{
"name": "list_labels",
"arguments": {}
}Contributing
Contributions are welcome! Please feel free to submit pull requests.
License
MIT License
Available Tools
13 toolsget_campaign_by_nameB
根據名稱獲取行動資訊
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | 行動名稱 |
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention whether the operation is read-only, what happens if the name is not found, or the structure of the returned information. The description is insufficient for a read operation.
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 very short (one sentence) and front-loaded with the key action and resource. It is efficient but could benefit from a bit more context.
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 simple tool with one parameter and no output schema, the description is adequate but does not explain the response format. Given the lack of annotations, it could be more 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?
Schema description coverage is 100% (one parameter 'name' described in both schema and description). The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('get') and resource ('campaign') with a filter ('by name'). It distinguishes from sibling tools like 'get_file_by_id' which retrieve by ID, but does not mention what '行動資訊' includes.
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?
No explicit guidance on when to use this tool versus alternatives like 'list_campaigns' or search tools. Usage is implied by the parameter, but no when-not or comparison is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_file_by_idA
根據ID獲取檔案資訊
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | 檔案ID |
TDQS
A3.5/5.0
Behavior2/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. It does not disclose behavioral traits such as read-only nature, required permissions, error handling (e.g., if ID not found), or rate limits. The description adds no detail beyond the name.
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 with no unnecessary words. It is front-loaded and 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?
For a simple get-by-id tool with one parameter and no output schema, the description is minimally adequate. However, it lacks details on return values, error conditions, or any behavioral nuances, leaving gaps for an AI agent.
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 coverage is 100% and the parameter 'id' is described. The description reinforces that the ID is used, but adds no additional meaning beyond the schema. Baseline 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 clearly states the tool's action: retrieving file information by ID. It distinguishes itself from sibling tools like list_files or search tools by specifying the retrieval method (by ID).
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 a file ID is available, but lacks explicit guidance on when to use this tool versus alternatives like list_files for browsing. No when-not or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_user_by_idB
根據ID獲取使用者資訊
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | 使用者ID |
TDQS
B3.2/5.0
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 says 'get user information' but does not indicate read-only nature, rate limits, or what exactly the returned information includes.
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 a single sentence, concise and to the point. It could be slightly more descriptive but is 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?
For a simple get-by-ID tool with one parameter and no output schema, the description is adequate but lacks detail on return format or scope. Given the context of many sibling tools, more completeness would help.
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% with a single 'id' parameter described. The description adds no extra meaning beyond the schema, hence baseline score of 3 is appropriate.
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 action 'get' and resource 'user information' by ID, distinguishing it from sibling tools like list_users or get_campaign_by_name.
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. Sibling tools exist for different resources or listing, but there are no explicit exclusions or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_attack_patternsC
列出所有攻擊模式
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| first | No | 返回結果數量限制 |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose behavioral traits such as read-only nature, pagination, authentication requirements, or side effects.
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?
Single sentence, front-loaded, efficient. Could include more detail without losing conciseness.
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 output schema and no annotations, description is too minimal to provide complete context for agent to use tool effectively.
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% with one parameter 'first' already documented in schema. Description adds no additional meaning beyond schema.
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?
Description clearly states 'list all attack patterns' in Chinese, specifying the verb and resource. Siblings are distinct resources, so no differentiation needed.
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 on when to use this tool versus alternatives, no context provided on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_connectorsA
列出所有連接器
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A3.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'list all connectors' without disclosing any behavioral traits such as idempotency or side effects.
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 sentence with no wasted words, efficiently conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is sufficient, though it lacks any mention of return format or behavior.
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?
There are no parameters, and schema coverage is 100%, so the description does not need to add parameter information; baseline 4 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 clearly specifies the verb 'list' and the resource 'connectors', distinguishing it from sibling tools that list other entities.
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; usage context is entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_filesC
列出所有檔案
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description fails to disclose behavioral traits such as system scope, pagination, permissions, or whether it lists all files in a workspace or globally. The agent receives no safety or behavioral cues.
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 a single concise sentence with no superfluous words. It is front-loaded and efficient, though it could benefit from structured details like scope or usage context.
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 (no parameters, no output schema, no annotations), the description is minimally adequate. However, it leaves open questions about what 'files' refers to and any implicit limitations, making it only moderately 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?
There are zero parameters, so schema coverage is 100%. The description adds no parameter meaning beyond stating 'all files', which aligns with the lack of filters. Baseline for 0 params is 4, but the description does not enrich understanding further.
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 '列出所有檔案' (list all files) clearly indicates the action and resource. It distinguishes from sibling tools like list_users or list_groups by specifying 'files', but does not provide additional scope or 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?
No usage guidance is provided. There is no mention of when to use this tool versus alternatives like get_file_by_id or other list tools, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_groupsB
列出所有群組
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| first | No | 返回結果數量限制 |
TDQS
B3.3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only states 'list all groups' without mentioning pagination, sorting, rate limits, or side effects. The parameter hinting at result limits is in the schema, not the description.
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 a single, front-loaded sentence with no wasted words. It earns its place by being concise, though it could be slightly more informative without losing brevity.
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 simplicity of the tool (one optional param, no output schema), the description is minimal. It omits context like what 'groups' refer to, scope, or behavioral details, which reduces completeness for an agent unfamiliar with the system.
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%—the only parameter 'first' has a description in the schema ('限制返回結果數量'). The tool description does not add any additional meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '列出所有群組' (List all groups) clearly states the action (list) and resource (groups), and distinguishes it from sibling tools targeting other resources like campaigns, files, users, etc.
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?
No explicit guidance on when to use this tool versus alternatives is provided. Usage is implied when the agent needs to list groups, but there is no mention of exclusions, prerequisites, or when another tool might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_labelsB
列出所有標籤
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'list all labels', implying no filtering but lacking details on authentication needs, rate limits, or any side effects. With no annotations, the description carries full burden and fails to disclose behavioral traits.
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, short sentence with no wasted words. It is front-loaded and 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 no parameters and no output schema, the description is minimally adequate. However, it does not explain what labels are or what the output looks like, leaving room for ambiguity. Sibling tools have similar brevity, but the lack of context reduces 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?
There are zero parameters, so the description does not need to add parameter meaning. The baseline of 4 applies as no parameter information is missing.
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 '列出所有標籤' (List all labels) clearly states the verb and resource. However, it does not differentiate from sibling list tools like list_attack_patterns or list_connectors, leaving ambiguity about what 'labels' refers to.
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. With many sibling list tools, the agent receives no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_marking_definitionsB
列出所有標記定義
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
B3.3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the action (listing) without describing side effects, authorization needs, or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that is front-loaded and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters, no output schema, and no annotations, the description is minimally complete—it states what it does. However, it could hint at output format or pagination, but this is not necessary.
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?
There are zero parameters, and schema coverage is 100%. The description adds the meaning that it lists marking definitions, which is beyond the empty schema. Baseline 4 applies.
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 lists all marking definitions. It uses a specific verb and resource, and the sibling tools list different entities, so the resource is distinct. However, it does not explicitly differentiate from siblings.
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 on when to use this tool versus alternatives. It does not provide context for when this tool is appropriate or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_status_templatesB
列出所有狀態模板
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like ordering, pagination, or performance implications. It only states the action, leaving the agent unsure about output format or limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly communicates the tool's purpose with no unnecessary words.
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 simple list tool with no parameters and no output schema, the description is minimally acceptable. It informs the agent of the basic operation but lacks details about what status templates are or the response format.
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?
There are zero parameters, so the schema is fully covered. The description does not add meaning beyond the schema, but the baseline for no parameters is 4.
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 lists all status templates, matching the name and distinguishing from sibling tools that list other resources. However, it does not explain what a status template is, relying on the name.
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 or any conditions. The description is merely a statement of functionality without context about typical use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_usersA
列出所有使用者
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A3.5/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only says 'list all users' without disclosing behavioral traits like pagination, permissions, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words.
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 simple list tool with no output schema, the description is minimally adequate but lacks details about return structure or potential limitations.
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?
There are 0 parameters, so the description does not need to add parameter information. Baseline is 4.
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 verb 'list' and resource 'users', and it distinguishes from siblings like get_user_by_id and list_groups.
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_user_by_id or search_threat_actors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_malwareC
搜尋OpenCTI中的惡意程式
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| first | No | 返回結果數量限制 | |
| query | Yes | 搜尋關鍵字 |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It only says 'search' without indicating whether it's read-only, returns partial data, or has any side effects. Minimal transparency.
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?
Single sentence, concise and to the point, but lacks structure like bullet points or additional context.
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?
No output schema provided, and description does not explain what the tool returns (e.g., list of IDs, full objects). Incomplete for a search 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% with descriptions for both parameters. Description adds no extra meaning beyond schema, so baseline 3 applies.
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?
Description clearly states it searches for malware in OpenCTI, with a specific verb and resource. However, it does not distinguish from sibling tools like search_threat_actors, which also perform searches.
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 on when to use this tool versus alternatives. Does not mention exclusions or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_threat_actorsB
搜尋OpenCTI中的威脅行為者
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| first | No | 返回結果數量限制 | |
| query | Yes | 搜尋關鍵字 |
TDQS
B3.2/5.0
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 disclosure. It does not mention read-only nature, potential side effects, rate limits, or what happens with no results. The text only repeats the purpose.
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 with no redundancy. It efficiently conveys the core functionality without extra words.
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?
With no output schema, the description should clarify return format or pagination behavior. It mentions neither, leaving agents underspecified about what to expect from the 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 description coverage is 100%, with both 'first' (limit) and 'query' having Chinese descriptions. The tool description adds no new meaning beyond the schema; baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for threat actors in OpenCTI, using specific verb '搜尋' and resource '威脅行為者'. It differentiates from siblings that target other entities like campaigns, malware, or users.
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 on when to use this tool versus alternatives such as search_malware or list_threat_actors. The description only states what it does, without providing contextual recommendations or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
13 tool updates
v1.0.1- First observed
get_campaign_by_name - First observed
get_file_by_id - First observed
get_user_by_id - First observed
list_attack_patterns - First observed
list_connectors - First observed
list_files - First observed
list_groups - First observed
list_labels - First observed
list_marking_definitions - First observed
list_status_templates - First observed
list_users - First observed
search_malware - First observed
search_threat_actors
TDQS
A3.5/5.0
Disambiguation5/5
每個工具都有明確的目標實體和操作（獲取、列出、搜尋），沒有重疊的職責。例如，get_campaign_by_name 與 search_threat_actors 針對不同實體，list_files 與 get_file_by_id 分別是列表和單一獲取，區分明確。
Naming Consistency5/5
工具名稱遵循一致的 verb_noun 模式：get_entity_by_field、list_entity、search_entity。例如 get_campaign_by_name、list_users、search_malware，風格統一且可預測。
Tool Count5/5
13 個工具涵蓋了 OpenCTI 平台的主要實體（如行動、檔案、使用者、攻擊模式等），數量合理且範圍適中，沒有過多或過少的問題。
Completeness3/5
工具集僅提供讀取和搜尋操作（get、list、search），缺乏建立、更新、刪除等寫入功能。雖然可能設計為唯讀介面，但對於完整的威脅情報生命週期來說有明顯缺口。
Maintenance
ActivitySlowing
ResponsivenessNo issues
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Cybersecurity MCP server for URL scanning, threat intelligence, and domain reputation.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceA server that implements the Model Context Protocol, providing a standardized way to connect AI models to different data sources and tools.1511MIT
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that integrates TAK Server with AI systems, providing geospatial-aware tools for querying, analyzing, and interacting with tactical data.10MIT
- FlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that connects AI assistants to MISP threat intelligence platforms. It enables threat intelligence search, IOC lookup, and event analysis through natural conversation.-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/zxzinn/opencti-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server