Skip to main content
Glama
siscale

Arcanna Input MCP Server

by siscale
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

Arcanna Input MCP Server

The Arcanna Input MCP server allows user to interact with Arcanna's AI use cases that use external api integration through the Model Context Protocol (MCP).

Usage with Claude Desktop or other MCP Clients

Configuration

Add the following entry to the mcpServers section in your MCP client config file (claude_desktop_config.json for Claude Desktop).

Use docker image (https://hub.docker.com/r/arcanna/arcanna-input-mcp-server) or PyPi package (https://pypi.org/project/arcanna-mcp-input-server)

Building local image from this repository

Prerequisites

Configuration

  1. Change directory to the directory where the Dockerfile is.

  2. Run docker build -t arcanna/arcanna-input-mcp-server . --progress=plain --no-cache

  3. Add the configuration bellow to your claude desktop/mcp client config.

{
  "mcpServers": {
    "arcanna-input-mcp-server": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "ARCANNA_INPUT_API_KEY",
        "-e",
        "ARCANNA_HOST",
        "-e",
        "ARCANNA_USER",
        "arcanna/arcanna-input-mcp-server"
      ],
      "env": {
        "ARCANNA_INPUT_API_KEY": "<YOUR_ARCANNA_API_KEY_HERE>",
        "ARCANNA_HOST": "<YOUR_ARCANNA_HOST_HERE>",
        "ARCANNA_USER": "<YOUR_USERNAME_HERE>"
      }
    }
  }
}

Related MCP server: Anam MCP Server

Features

  • Job Management: Create, retrieve, start, stop, and train jobs

  • Event Processing: Send events for AI-powered decision making

  • Feedback System: Provide feedback on decisions to improve model accuracy

  • Health Monitoring: Check server and API key status

Tools

Job Management

  • get_external_input_jobs

    • Retrieve all jobs associated with your API key

    • Returns a list of job details including status, labels, and processing metrics

  • get_external_input_job_by_id

    • Retrieve specific job details by ID

  • get_external_input_job_by_name

    • Retrieve specific job details by name

  • get_external_input_job_labels

    • Retrieve decision labels for a specific job

Event Management

  • send_event_to_external_input_job

    • Submit an event to Arcanna for AI decision-making

  • send_event_with_id_to_external_input_job

    • Submit an event with a custom identifier

System Health

  • health_check_input_server

    • Verify server status and API key validity

    • Returns API key authorization status

Available Tools

4 tools
get_external_input_jobsA
    Retrieve Arcanna External Input Jobs.
    An Arcanna External Input Job refers to a job where the user's API Key is configured on the input integration, enabling data to be sent via HTTP calls.
    Use this tool only when:
        - 1. The user intends to send data to Arcanna
             Example user query: "I want to start pushing/send data to Arcanna. What jobs can I use?"
        - 2. The user specifically requests jobs configured with an external API Key
             Example user query: "Can you show me the jobs that use an external API key input?"

    DO NOT use this tool outside the specific scenarios described. If you're unsure, ask the user for clarification before proceeding.
    DO NOT use this tool if the user is requesting a generic job retrieval, such as:
        - 1. "What are the available jobs?"
        - 2. "What jobs are in Arcanna?"
        - 3. "List the jobs."
        - 4. "Show the jobs."
        In such cases, use a different tool designed for general job listing instead.

Returns:
--------
list
    A list of dictionaries, each representing job details with the following keys:

    - job_id (int): Unique identifier for the job.
    - category (str): Category of the job.
    - title (str): Title or name of the job.
    - status (str): Current status of the job (e.g., ENABLED - the job is ingesting events. DISABLED - the job is stopped.
     READY_TO_SELECT_FEATURES - user must select decision points. etc.).
    - retrain_state (str): State of the retraining process.
    - retrain_msg (str): Message providing details about the retraining process.
    - labels (list of str): List of decision labels associated with the job.
    - features (list of str): List of decision points used in the job.
    - processed_documents_count (int): Number of events processed.
    - feedback_documents_count (int): Number of events that received feedback.
    - last_processed_timestamp (str): Timestamp of the last processed event.
    - last_feedback_timestamp (str): Timestamp of the last received feedback.
    - last_train_start_timestamp (str): Timestamp when the last training started.
    - last_train_finished_timestamp (str): Timestamp when the last training finished.
    - invalid (bool): Indicates whether the job is invalid (True/False).
ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It describes the return type and fields in detail, implying a read operation. However, it does not explicitly state the absence of side effects, auth requirements, or potential errors (e.g., empty result set).

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?

Well-structured with bullet points and front-loaded purpose. Slightly verbose in the return list but each element adds value. Could be slightly more concise, but effective.

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?

Comprehensive for a zero-parameter tool with no output schema. Provides detailed return field descriptions, clear usage guidelines, and sufficient context to understand when to invoke.

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?

No parameters, schema_description_coverage is 100%, so baseline is 4. The description adds context about what the tool returns, which is appropriate since the schema is empty.

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 'Retrieve Arcanna External Input Jobs' and explains the specific resource. It distinguishes from sibling tools by specifying when to use, using specific verb and resource.

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?

Provides explicit when-to-use scenarios with examples, and clearly lists cases where the tool should NOT be used, directing to a different tool for general job listing. This helps the agent avoid misuse.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

health_check_input_serverA
    Health check of Arcanna Input API Server.
    Returns:
    --------
    dict
        - status (bool): If false, the server is up an running but API key is invalid. If true, api key is also
        authorized
ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4/5.0
Behavior3/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 explains the return dict and the meaning of the 'status' field, which helps the agent understand outcomes. However, it does not disclose potential side effects, auth requirements, 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 very concise: two short paragraphs with no wasted words. The purpose is front-loaded, and the return details are clearly separated.

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 health check tool with no parameters and no output schema, the description sufficiently explains the return value. It could mention authentication implications, but the current level is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the description does not need to add parameter-level information. The baseline score of 4 is appropriate as it is not missing any parameter details.

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 'Health check' and the resource 'Arcanna Input API Server'. This distinguishes it from sibling tools like get_external_input_jobs or send_event_to_external_input_job, which deal with jobs and events.

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 purpose is self-evident as a health check, but there is no explicit guidance on when to use it versus alternatives, nor any when-not conditions. The description implies usage for verifying server status but lacks clarity on decision boundaries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

send_event_to_external_input_jobA
Send a JSON event payload for Arcanna to provide a decision on. Arcanna will generate a new internal ID for the event.
In case of an internal server error, do not use any other tool, ask the user how he would like to continue,
Parameters:
-----------
job_id : int
    Unique identifier for the external input job.
event : dict
    A raw dictionary containing event/alert/incident data.

Returns:
--------
dict
    A dictionary containing event tracking details with the following keys:

    - event_id (str): Unique identifier for the event.
    - job_id (int): Unique identifier of the job where the event has been sent to.
    - ingest_timestamp (str): Timestamp when the data was ingested.
    - status (str): Status that tells if the event has been sent to ingestion successfully
    - error_message (str): Error details in case of failure; empty if successful.
ParametersJSON Schema
NameRequiredDescriptionDefault
job_idYes
eventYes

TDQS

A3.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must fully convey behavioral traits. It mentions that Arcanna generates a new internal ID, but it does not disclose potential side effects, required permissions, rate limits, or the impact of sending data. The error-handling note is helpful but insufficient for full 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?

The description is front-loaded with the purpose, followed by an error-handling note, then a parameter list. It is relatively concise, though the 'Parameters:' header and empty line add slight redundancy. The structure is clear but could be tighter.

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 includes return value details despite no output schema, which is good. However, it does not specify the expected format or keys for the event dictionary, leaving ambiguity for nested objects. It also fails to differentiate from sibling tools or explain prerequisites. Overall, adequate for a simple tool but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, but the description adds meaning: job_id as 'Unique identifier for the external input job' and event as 'A raw dictionary containing event/alert/incident data.' This compensates for the missing schema descriptions and provides clarity beyond the 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 clearly states the action: send a JSON event payload to Arcanna for a decision, generating a new internal ID. This distinguishes it from the sibling tool 'send_event_with_id_to_external_input_job', which presumably takes an existing ID. The verb and resource are specific and unambiguous.

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?

While the description provides an error-handling instruction ('do not use any other tool, ask the user'), it lacks explicit guidance on when to use this tool versus the sibling tools. It implies use for new events without an ID, but this is not directly stated. No exclusions or alternatives are described.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

send_event_with_id_to_external_input_jobA
Send a JSON security alert/incident/event to Arcanna for ingestion.

Parameters:
-----------
job_id : int
    Unique identifier for the external input job.
event : dict
    A raw dictionary containing event/alert/incident data.
event_id: str
    Unique identifier for the event.

Returns:
--------
dict
    A dictionary containing event tracking details with the following keys:

    - event_id (str): Unique identifier for the event.
    - job_id (int): Unique identifier of the job where the event has been sent to.
    - ingest_timestamp (str): Timestamp when the data was ingested.
    - status (str): Status that tells if the event has been sent to ingestion successfully
    - error_message (str): Error details in case of failure; empty if successful.
ParametersJSON Schema
NameRequiredDescriptionDefault
job_idYes
eventYes
event_idYes

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It states that the tool sends data to Arcanna and returns a dict with status and error_message, implying mutation and potential failure. However, it does not disclose authorization requirements, rate limits, idempotency, or whether it is destructive. The description is adequate but not thorough given the lack of 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 is well-structured with a clear summary sentence followed by 'Parameters:' and 'Returns:' sections using bullet points. It is front-loaded with the main purpose. However, the parameter descriptions are redundant with the argument list (though needed due to schema deficiencies), and the return section could be slightly more concise. Still, it earns its place.

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 explains all parameters and the return value, which is helpful. However, it assumes the agent knows that job_id must correspond to an existing external input job (presumably retrievable via 'get_external_input_jobs'), and it does not mention any dependencies or setup steps. The return value includes error_message but no explanation of error handling. Given the tool's complexity (3 required params, nested object), it is partially complete.

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 0% description coverage, meaning it provides no descriptions for parameters. The tool's description explicitly describes each parameter (job_id as int referencing an external input job, event as raw dict, event_id as unique identifier), adding significant meaning beyond the schema. It also details the return value structure, which is absent from any output 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 action ('Send') and the resource ('a JSON security alert/incident/event to Arcanna for ingestion'). It distinguishes from the sibling 'send_event_to_external_input_job' by including 'with_id' in the name and describing the event_id parameter, indicating this variant allows sending with a specific event identifier.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide any guidance on when to use this tool versus the sibling 'send_event_to_external_input_job' (without event_id). It lacks context on prerequisites (e.g., needing to obtain a job_id from 'get_external_input_jobs') or when not to use it. No alternatives are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation4/5

Tools are mostly distinct: listing jobs, health check, and two event-sending variants. The two send tools are similar but clearly differentiated by the presence of an optional event_id. Some potential for confusion but descriptions clarify.

Naming Consistency3/5

Names use snake_case but patterns vary: 'get_external_input_jobs' is verb_noun, 'health_check_input_server' is noun_verb_noun, while the send tools follow verb_noun_prep_noun. Inconsistent use of singular/plural ('jobs' vs 'job').

Tool Count5/5

Four tools are well-scoped for an input server: one to list available jobs, one for health check, and two for sending events (with/without custom ID). No unnecessary tools.

Completeness4/5

Covers core operations: listing jobs, health check, and event ingestion. Missing functionality like retrieving event status or updating/deleting events, but these may be out of scope for an input-focused server.

Maintenance

ActivityInactive
ResponsivenessSyncing

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

Related MCP Servers

  • Manus MCP

    nanameru
    A
    license
    B
    quality
    D
    maintenance
    Enables integration with Manus AI to create AI tasks with custom prompts, manage webhooks for real-time notifications, and leverage attachments and connectors within MCP-compatible clients.
    3
    92
    4
    MIT

  • h2ogpte-mcp-server

    h2oai
    A
    license
    Not graded
    quality
    A
    maintenance
    Enables interaction with H2OGPTe's REST API, allowing document ingestion, collection management, and chat with AI models through MCP tools and resources.
    1
    Apache 2.0

Latest Blog Posts

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/siscale/arcanna-mcp-input-server'

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