Skip to main content
Glama
deenesjakoruzh
jentic

Jentic

Official
by jentic
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

Jentic MCP Plugin

Why Use Jentic MCP?

Jentic MCP empowers developers to discover and integrate external APIs and workflows rapidly—without the need to write or maintain any API-specific code. By leveraging the MCP protocol and Jentic’s agentic runtime, developers can:

  • Search for APIs and workflows by capability, not by vendor or implementation.

  • Instantly generate integration code samples that are agnostic to specific API details.

  • Avoid boilerplate and reduce maintenance by relying on standardized, declarative integration.

  • Focus on building features, while Jentic MCP handles the complexity of API interaction.

Related MCP server: agent-zone-mcp

API Tools

The Jentic MCP Plugin provides the following tools:

  1. search_apis: Search for APIs in the Jentic directory that match specific functionality needs

  2. load_execution_info: Retrieve detailed specifications for APIs and operations from the Jentic directory. This will include auth information you may need to provide in your mcpServers.jentic.env configuration.

  3. execute: Execute a specific API or workflow operation.

Getting Started

The recommended method is to run the server directly from the GitHub repository using uvx. You will need to install uv first using:

brew install uv or pip install uv

Agent API Key

Create an agent at https://app.jentic.com/sign-in and copy its API key.

export JENTIC_AGENT_API_KEY=<your-agent-api-key>

Set the key in your MCP client configuration as shown below.

The location of the configuration file depends on the client you are using and your OS. Some common examples:

  • Windsurf: ~/.codeium/windsurf/mcp_config.json

  • Claude Desktop: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Claude Code: ~/.claude.json

  • Cursor: ~/cursor/.mcp.json

For other clients, check your client's documentation for how to add MCP servers.

{
    "mcpServers": {
        "jentic": {
            "command": "uvx",
            "args": [
                "--from",
                "git+https://github.com/jentic/jentic-sdks.git@main#subdirectory=mcp",
                "mcp"
            ],
            "env": {
                "JENTIC_AGENT_API_KEY": "<your-agent-api-key>"
            }
        }
    }
}

Note: After saving the configuration file, you may need to restart the client application (Windsurf, Claude Desktop) for the changes to take effect.

MCP Tool Use

Once the MCP server is running, you can easily use the MCP tools in your LLM agent to discover and execute APIs and workflows.

  1. search_apis: Search for APIs in the Jentic directory that match specific functionality needs

  2. load_execution_info: Retrieve detailed specifications for APIs and operations from the Jentic directory. This will include auth information you may need to provide in your mcpServers.jentic.env configuration.

  3. execute: Execute a specific API or workflow operation.

Environment Variables

When you are using an API that requires authentication, the load_execution_info tool will describe the required environment variables. You environment variables via the command line in Windsurf, although in some clients like Claude Desktop, you'll need to add them to your MCP config:

{
    "mcpServers": {
        "jentic": {
            "command": "uvx",
            "args": [
                "--from",
                "git+https://github.com/jentic/jentic-sdks.git@main#subdirectory=mcp",
                "mcp"
            ],
            "env": {
                "DISCORD_BOTTOKEN=": "YOUR BOT TOKEN"
            }
        }
    }
}

Alternative (Using Local Path for Development):

Use this if you are actively developing the MCP plugin locally. Replace /path/to/your/project/mcp with the absolute path to your project directory.

{
    "mcpServers": {
        "jentic": { 
            "command": "uvx",
            "args": [
                "--from",
                "/path/to/your/project/mcp",
                "mcp" 
            ]
        }
    }
}

Optional: Add a JENTIC_API_URL environment variable to your mcp_config.json file to point to a specific Jentic API (works with both methods):

{
    "mcpServers": {
        "jentic": {
            "command": "uvx",
            "args": [
                "--from",
                "git+https://github.com/jentic/jentic-sdks.git@main#subdirectory=mcp",
                "mcp"
            ],
            "env": {
                "JENTIC_API_URL": "https://your-jentic-api.url/"
            }
        }
    }
}

Once configured, restart Windsurf, and the Jentic MCP tools will be available.

You can tail the logs generated by the locally running MCP server by running:

tail /path/to/mcp/jentic_ark2_mcp.log

Installation

Installing via Smithery

To install Jentic Plugin for Claude Desktop automatically via Smithery:

npx -y @smithery/cli install @jentic/jentic-sdks --client claude

Manual Installation

Ensure you have pdm installed (pipx install pdm).

To install the package and its dependencies for development:

# From the project root directory (e.g., /Users/kc/c/sdk/mcp)
pdm install -G dev

Running the MCP Server

The Jentic MCP plugin is designed to be run using uvx, which handles environment setup and execution.

Default Mode (Stdio)

Run the MCP plugin directly using uvx, specifying the project directory as the source using --from and the mcp script:

From Local Path (Development):

# Use --from with the project directory and specify the 'mcp' script
uvx --from /path/to/your/project/mcp mcp

# Or, if running from within the project directory:
uvx --from . mcp

From Remote Repository (Recommended for general use):

uvx --from \
  git+https://github.com/jentic/jentic-sdks.git@main#subdirectory=mcp \
  mcp

This automatically uses the default serve --transport stdio command defined in the mcp script's callback.

HTTP Modes

The MCP server supports two HTTP transport modes:

  • Standard HTTP: Traditional request-response HTTP mode

  • Streamable HTTP: HTTP mode with streaming support, compatible with MCP Inspector

Standard HTTP Mode

To run the server in standard HTTP mode (e.g., for testing with claude-cli):

From Local Path (Development):

# Default HTTP (port 8010)
uvx --from /path/to/your/project/mcp mcp serve --transport http

# With custom port
uvx --from /path/to/your/project/mcp mcp serve --transport http --port 8080

# With custom host
uvx --from /path/to/your/project/mcp mcp serve --transport http --host 0.0.0.0 --port 8080

From Remote Repository (Recommended):

uvx --from \
  git+https://github.com/jentic/jentic-sdks.git@main#subdirectory=mcp \
  mcp serve --transport http --port 8080

Streamable HTTP Mode

To run the server in streamable HTTP mode (compatible with MCP Inspector):

From Local Path (Development):

# Default streamable HTTP (port 8010)
uvx --from /path/to/your/project/mcp mcp serve --transport streamable-http

# With custom port
uvx --from /path/to/your/project/mcp mcp serve --transport streamable-http --port 8080

# With custom host
uvx --from /path/to/your/project/mcp mcp serve --transport streamable-http --host 0.0.0.0 --port 8080

From Remote Repository (Recommended):

uvx --from \
  git+https://github.com/jentic/jentic-sdks.git@main#subdirectory=mcp \
  mcp serve --transport streamable-http --port 8080

Running from a Remote Git Repository

You can also run the MCP server directly from a Git repository URL without cloning it locally using uvx --from:

# Example from a specific branch and subdirectory
uvx --from \
  git+https://github.com/jentic/jentic-sdks.git@main#subdirectory=mcp

# Explanation:
# - git+https://... .git : The repository URL
# - @main   : The branch, tag, or commit hash
# - #subdirectory=mcp     : The folder within the repo containing the pyproject.toml

This command fetches the specified version, installs its dependencies in a temporary environment, and runs the default command (which is serve --transport stdio).

You can add other arguments like --log-level DEBUG or --mock after the URL fragment:

uvx --from \
  git+https://github.com/jentic/jentic-sdks.git@main#subdirectory=mcp \
  --log-level DEBUG --mock

To run in HTTP mode from a remote source:

uvx --from \
  git+https://github.com/jentic/jentic-sdks.git@main#subdirectory=mcp \
  serve --transport http --port 8080

To run in streamable HTTP mode from a remote source:

uvx --from \
  git+https://github.com/jentic/jentic-sdks.git@main#subdirectory=mcp \
  serve --transport streamable-http --port 8080

Other Options

Logging

# Set logging level (applies to default stdio or explicit serve)
uvx --from /path/to/your/project/mcp mcp --log-level DEBUG
uvx --from /path/to/your/project/mcp mcp serve --transport http --log-level DEBUG
uvx --from /path/to/your/project/mcp mcp serve --transport streamable-http --log-level DEBUG

# Log to file (applies to default stdio or explicit serve)
uvx --from /path/to/your/project/mcp mcp --log-file jentic_mcp.log
uvx --from /path/to/your/project/mcp mcp serve --transport http --log-file jentic_mcp.log
uvx --from /path/to/your/project/mcp mcp serve --transport streamable-http --log-file jentic_mcp.log

Mock Mode

Enable mock mode for development without connecting to the actual Jentic API Knowledge Hub:

# Mock mode with default stdio
uvx --from /path/to/your/project/mcp mcp --mock

# Mock mode with explicit HTTP
uvx --from /path/to/your/project/mcp mcp serve --transport http --mock

# Mock mode with streamable HTTP
uvx --from /path/to/your/project/mcp mcp serve --transport streamable-http --mock

Environment Variables

Provide environment variables using a .env file:

# Env file with default stdio
uvx --from /path/to/your/project/mcp mcp --env-file .env

# Env file with explicit HTTP
uvx --from /path/to/your/project/mcp mcp serve --transport http --env-file .env

# Env file with streamable HTTP
uvx --from /path/to/your/project/mcp mcp serve --transport streamable-http --env-file .env

Using with Claude

The MCP plugin can be used with Claude or other LLMs that support the MCP specification:

Run from Remote Repository (Recommended):

# Run the server in HTTP mode first
uvx --from \
  git+https://github.com/jentic/jentic-sdks.git@main#subdirectory=mcp \
  mcp serve --transport http --port 8000

# Then connect claude-cli
claude-cli --mcp http://localhost:8000

Run from Local Path (Development):

# Run the server in HTTP mode first
uvx --from /path/to/your/project/mcp mcp serve --transport http --port 8000

# Then connect claude-cli
claude-cli --mcp http://localhost:8000

Development

See CLAUDE.md for detailed development instructions.

Package Structure

  • src/mcp/: Main MCP package

    • mock/: Mock data providers for development

    • tools.py: Tool definitions

    • handlers.py: Request handlers

    • main.py: CLI entry points

    • adapters/: Adapter implementations

    • core/: Core functionality

  • tests/: Test suite

Testing

# Ensure dev dependencies are installed: pdm install -G dev
pdm run test

Linting & Formatting

Uses ruff, black, isort, mypy via pdm scripts.

# Run all linters/formatters
pdm run lint

# Run only ruff
pdm run linter

Available Tools

3 tools
executeC

Perform the chosen action for the user using the provided details (if any are needed).

ParametersJSON Schema
NameRequiredDescriptionDefault
execution_typeYesSpecify whether to execute an 'operation' or a 'workflow'.
inputsYesThe input parameters required by the operation or workflow.
uuidYesThe UUID of the operation or workflow to execute.

TDQS

C2.4/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states 'perform the chosen action' which implies a write/mutation operation, but doesn't disclose critical behavioral traits: whether this is synchronous/asynchronous, what permissions are required, whether it's idempotent, what happens on failure, or what the response contains. For a tool that appears to execute potentially complex operations/workflows, this is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that gets straight to the point without unnecessary words. However, this conciseness comes at the cost of being under-specified for a tool with three required parameters and no annotations - it could benefit from one more clarifying sentence about what gets executed.

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?

For a tool with 3 required parameters (including a nested object), no annotations, and no output schema, the description is inadequate. It doesn't explain what types of actions can be executed, what the expected outcomes are, or provide any error handling context. The agent would struggle to use this tool effectively without trial and error.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no parameter-specific information beyond the generic 'using the provided details' - it doesn't clarify the relationship between execution_type, uuid, and inputs, or provide examples of valid input objects. Baseline 3 is appropriate when the schema does all the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Perform the chosen action for the user using the provided details' is tautological - it essentially restates the tool name 'execute' without specifying what kind of actions or resources are involved. While it mentions 'chosen action' and 'provided details', it doesn't clarify whether this executes operations, workflows, scripts, or other entities, nor does it distinguish this from sibling tools like 'load_execution_info' or 'search_apis'.

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

Usage Guidelines2/5

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

The description provides minimal guidance - it mentions 'chosen action' and 'provided details' but gives no explicit when-to-use criteria, no prerequisites, and no comparison to alternatives like 'load_execution_info' (which presumably loads execution information rather than performing execution) or 'search_apis'. The agent must infer usage from the parameter schema alone.

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

load_execution_infoC

Get more details about a specific action (like what information it needs from the user) before confirming you want to run it. Usually used if the action requires specific inputs. Coding Agents: To provide tools to an LLM that you have selected at runtime, use this tool to retrieve the necessary information and save it to 'jentic.json' at the root of your project.

ParametersJSON Schema
NameRequiredDescriptionDefault
operation_uuidsYesThe UUIDs of the operations to include in the configuration files.
workflow_uuidsYesThe UUIDs of the workflows to include in the configuration files.

TDQS

C2.5/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden but offers limited behavioral insight. It mentions retrieving information and saving to a file, but doesn't disclose critical traits like whether this is a read-only operation, if it modifies state, authentication needs, rate limits, or error handling. The description adds some context but leaves significant gaps.

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 moderately concise but not optimally structured. The first sentence clearly states the purpose, but the second sentence adds implementation details for coding agents that may not apply to all users. The information is somewhat front-loaded but could be more focused.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description should provide more complete context. It mentions retrieving details and saving to a file, but doesn't explain what format the details take, what 'jentic.json' contains, or what happens if parameters are invalid. For a tool with 2 required parameters and mutation implications, this is inadequate.

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

Parameters3/5

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

Schema description coverage is 100%, so parameters are well-documented in the schema. The description doesn't add meaningful semantic context beyond what the schema provides about operation_uuids and workflow_uuids. It mentions 'configuration files' but doesn't clarify how parameters relate to this output.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool 'Get more details about a specific action' which indicates its purpose, but it's vague about what 'details' means and doesn't clearly differentiate from sibling tools like 'execute' or 'search_apis'. It mentions saving to 'jentic.json' which adds specificity but confuses the core purpose with implementation details for coding agents.

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

Usage Guidelines2/5

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

The description provides some guidance ('Usually used if the action requires specific inputs') but lacks explicit when-to-use vs. alternatives. It doesn't clarify when to choose this over 'execute' or 'search_apis', and the coding agent note is situational rather than general usage guidance.

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

search_apisA

Search for available actions or information based on what the user wants to do (e.g., 'find Discord servers', 'send a message'). Use this first to understand what's possible.

ParametersJSON Schema
NameRequiredDescriptionDefault
capability_descriptionYesNatural language description of the action needed (e.g., 'send emails', 'weather forecasting', 'natural language processing')
keywordsNoOptional list of specific keywords to help narrow down the search
max_resultsNoMaximum number of actions to return

TDQS

A3.6/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 the full burden of behavioral disclosure. It mentions the tool searches for actions or information but lacks details on behavioral traits such as response format, error handling, rate limits, or authentication needs. For a search tool with zero annotation coverage, this is a significant gap, though it does imply it returns results (e.g., 'to return' in the schema).

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 and front-loaded, with two sentences that efficiently convey purpose and usage guidelines. Every sentence earns its place by providing essential information without redundancy. It could be slightly more concise by integrating examples more seamlessly, but overall it's well-structured.

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 moderate complexity (3 parameters, no output schema, no annotations), the description is adequate but has clear gaps. It covers purpose and usage well but lacks behavioral details like return format or error handling. Without annotations or an output schema, the description should do more to compensate, making it minimally viable but incomplete.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description does not add any additional meaning beyond what the schema provides, such as explaining how 'capability_description' interacts with 'keywords' or detailing search algorithms. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Search for available actions or information based on what the user wants to do.' It provides a specific verb ('search') and resource ('available actions or information'), with examples like 'find Discord servers' and 'send a message' to illustrate usage. However, it doesn't explicitly distinguish this from sibling tools like 'execute' or 'load_execution_info', which prevents a perfect score.

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

Usage Guidelines5/5

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

The description provides explicit guidance on when to use this tool: 'Use this first to understand what's possible.' This clearly indicates it should be employed as an initial step to discover capabilities before invoking other tools, effectively differentiating it from siblings like 'execute' (which likely performs actions) and 'load_execution_info' (which might retrieve details).

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.

  1. 3 tool updatesv1.0.0
    • First observedexecute
    • First observedload_execution_info
    • First observedsearch_apis
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.9/5.0
Disambiguation4/5

The tools have distinct primary purposes: 'search_apis' discovers available actions, 'load_execution_info' retrieves details for a specific action, and 'execute' performs the action. There is minor potential overlap between 'load_execution_info' and 'execute' in handling action details, but the descriptions clarify their sequential workflow roles.

Naming Consistency3/5

The naming is mixed: 'search_apis' and 'load_execution_info' use snake_case with descriptive verbs, while 'execute' is a single verb without a noun. This inconsistency in structure (two tools follow a verb_noun pattern, one does not) reduces predictability, though the names remain readable.

Tool Count4/5

With 3 tools, the count is reasonable for a server focused on action discovery and execution. It feels slightly thin but covers core workflows (search, detail retrieval, execution), avoiding bloat. A few more tools might enhance completeness, but this is a solid minimal set.

Completeness3/5

The tool set covers a basic workflow (search, load info, execute) for action-based operations, but there are notable gaps. For example, there's no tool for managing or listing previously executed actions, error handling, or status checks, which could limit agent effectiveness in more complex scenarios.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

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

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/jentic/jentic-sdks'

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