HefestoAI

Name: HefestoAI
Author: artvepa80

Server Details

Pre-commit code quality guardian. Detects semantic drift in AI-generated code.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 54 days
Last Tested: 2026-10-10 23:56
Transport: Streamable HTTP · MCP 2024-11-05
URL
Repository: artvepa80/Agents-Hefesto
GitHub Stars: 1

TDQS

A3.7/5.0

Scored 2026-08-01 07:35 across 4 tools

Disambiguation5/5

Each tool targets a distinct aspect: analyzing code, comparing tools, getting installation steps, and retrieving pricing information. There is no overlap or ambiguity among them.

Naming Consistency5/5

All tool names are single lowercase verbs (analyze, compare, install, pricing), forming a consistent and predictable pattern. No mixed naming conventions.

Tool Count5/5

With 4 tools, the server is tightly scoped to its purpose. Each tool is necessary and covers the primary user intents without overloading the surface.

Completeness4/5

The tool set covers the main user journey: analyze code, compare with alternatives, install, and get pricing. Minor gaps like detailed documentation or troubleshooting are missing, but the core purpose is well-served.

Available Tools

4 tools

analyzeInspect

Runs the open-source hefesto-ai engine (hefesto analyze --no-config, free tier) on the files you send and returns its findings: rule id, severity, file, line, message and the SARIF hefestoFingerprint/v1 fingerprint (format "sarif" adds the full SARIF 2.1.0 log). Covers Python, COBOL, the DevOps/IaC formats hefesto analyze routes, and TypeScript, JavaScript, Java, Go, Rust and C# through the multilang tree-sitter grammars (the first such request on a fresh server instance downloads the grammars and can take a few seconds longer). Limits: 20 files, 100 KB per file, 256 KB in total, 20 seconds. No .hefesto.yaml is read. Files are deleted after the run; nothing is stored.

ParametersJSON Schema

Name	Required	Description
`code`	No	A single snippet, used when files is not given (written as e.g. snippet.py for language python).
`files`	No	Files to analyze. path: relative POSIX path (letters, digits, '_', '.', '-'; no '..', no absolute paths); content: UTF-8 text.
`format`	No	json (default): findings only; sarif: also the full SARIF 2.1.0 log.
`language`	No	Language of code: python (default), cobol, yaml, dockerfile, terraform, shell, sql, javascript, typescript, java, go, rust, csharp.
`severity`	No	Minimum severity to report (default LOW).

compareCInspect

Compare HefestoAI with other code quality tools

ParametersJSON Schema

Name	Required	Description	Default
`tool`	No	Tool to compare with (sonarqube, snyk, github-advanced-security, semgrep, claude-code-security)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of disclosing behavior. It only states the action without noting whether the comparison is live or static, what output is returned, or any side effects or prerequisites. This is a significant transparency gap for a tool that produces results.

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, direct sentence with no unnecessary words. It is front-loaded with the verb and resource, making it highly concise and easy to parse.

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 simple tool with one optional parameter and no output schema, the description is too sparse. It does not explain what the comparison results look like, how to interpret them, or any operational details, leaving the agent without enough context to use it confidently.

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

Parameters3/5

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

The input schema already provides 100% coverage of the single parameter, listing acceptable values in its description. The tool description adds no additional semantics, but the schema handles the parameter meaning adequately, so the baseline of 3 is appropriate.

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

Purpose4/5

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

The description clearly identifies the action ('Compare') and the resource being compared (HefestoAI vs. other code quality tools), and it distinguishes from sibling tools like analyze, install, and pricing. However, it does not specify what aspects are compared or the format of the comparison, so it is slightly under-specified.

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 no guidance on when to use this tool versus alternatives. It does not mention scenarios, exclusions, or related tools, leaving the agent to infer usage from the name alone.

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

installAInspect

Get installation instructions for HefestoAI

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/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 indicates the tool is informational ('Get installation instructions'), implying a read-only, non-destructive action. However, it does not disclose details like return format or whether instructions vary by platform, which would be useful but not critical for a zero-parameter tool.

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

Conciseness5/5

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

The description is a single, concise sentence with no filler or redundant information. It states exactly what the tool does without wasting 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?

Given the tool's simplicity (no parameters, no output schema, no annotations), the description adequately covers all necessary context. It fully explains the tool's purpose and behavior. A slightly more detailed description might mention the content of the instructions, but the current scope is sufficient.

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 and the schema coverage is trivially 100%, so the description does not need to explain parameters. The description adds no parameter details, but none are needed. Baseline of 4 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 uses a specific verb 'Get' and identifies the resource 'installation instructions for HefestoAI', making the tool's purpose clear. It also differentiates from siblings like analyze, compare, and pricing, which serve different functions.

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

Usage Guidelines4/5

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

The description clearly implies when to use the tool: when installation instructions for HefestoAI are needed. While it does not explicitly state when not to use it or name alternatives, the context is clear enough for this simple procedural tool, and no competing sibling serves the same purpose.

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

pricingAInspect

Get HefestoAI pricing information

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior3/5

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

No annotations are provided, and the description simply states 'Get HefestoAI pricing information.' The verb implies a read operation, but no details are given about return format, data source, or any potential side effects. It is minimally transparent but not misleading.

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, front-loaded sentence with no filler or redundant information. Every word adds meaning.

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, zero-parameter information-retrieval tool, the description is complete enough to indicate the purpose and expected return content. It lacks details about formatting or pricing specifics, but the scope is straightforward.

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 schema already covers everything. With no parameters to document, the description adequately covers parameter semantics by not needing to add anything.

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 uses a clear verb ('Get') and specific resource ('HefestoAI pricing information'), making the tool's purpose immediately obvious. However, it does not explicitly differentiate this from sibling tools like compare or install, though pricing information is distinct enough.

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 about when to use this tool versus alternatives such as analyze, compare, or install. The description gives no context, prerequisites, 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.

1 tool updateOct 10, 2026

Changedanalyze5 fields changed

changedInput schema / properties / code / description

Previous value: -"Ignored. Accepted for backward compatibility; run hefesto analyze locally to analyze code."New value: +"A single snippet, used when files is not given (written as e.g. snippet.py for language python)."

addedInput schema / properties / files

Added value: +{
+  "description": "Files to analyze. path: relative POSIX path (letters, digits, '_', '.', '-'; no '..', no absolute paths); content: UTF-8 text.",
+  "items": {
+    "properties": {
+      "content": {
+        "type": "string"
+      },
+      "path": {
+        "maxLength": 200,
+        "type": "string"
+      }
+    },
+    "required": [
+      "path",
+      "content"
+    ],
+    "type": "object"
+  },
+  "maxItems": 20,
+  "type": "array"
+}

addedInput schema / properties / format

Added value: +{
+  "description": "json (default): findings only; sarif: also the full SARIF 2.1.0 log.",
+  "enum": [
+    "json",
+    "sarif"
+  ],
+  "type": "string"
+}

changedInput schema / properties / language / description

Previous value: -"Ignored. Accepted for backward compatibility."New value: +"Language of code: python (default), cobol, yaml, dockerfile, terraform, shell, sql, javascript, typescript, java, go, rust, csharp."

addedInput schema / properties / severity

Added value: +{
+  "description": "Minimum severity to report (default LOW).",
+  "enum": [
+    "LOW",
+    "MEDIUM",
+    "HIGH",
+    "CRITICAL"
+  ],
+  "type": "string"
+}

1 tool updateOct 9, 2026

Changedanalyze3 fields changed

changedInput schema / properties / code / description

Previous value: -"Code snippet to analyze"New value: +"Ignored. Accepted for backward compatibility; run hefesto analyze locally to analyze code."

changedInput schema / properties / language / description

Previous value: -"Programming language (python, javascript, etc)"New value: +"Ignored. Accepted for backward compatibility."

changedInput schema / required

Previous value: -[
-  "code"
-]New value: +[]

4 tool updatesFeb 24, 2026
- First observedanalyze
- First observedcompare
- First observedinstall
- First observedpricing

Related MCP Connectors

code-auditor-mcp
io.github.BenAHammond
Enforces architectural invariants and code quality rules inside your AI agent's edit loop.
318
Panel Review A
ai.truverif
Guardian agent for AI coding: four frontier models review risky diffs and commits before they ship.
Code Analysis AI & Machine Learning Developer Tools
1012
Moltline Code Review A
com.moltlinestudio
Risk-scan a diff, flag AI-generated-code tells, find secrets. 5 of 7 tools need no account.
Code Analysis Developer Tools Testing & QA Tools
71
Python Code Validator A
ai.statemind
Proves AI-generated Python does what you asked: lint, types, security, sandbox run, exact fixes.
Code Analysis Code Execution Developer Tools
31

Related MCP Servers

NormSync
Developer Tools Code Analysis Autonomous Agents
sandeep-alluru
A
license
Not graded
quality
F
maintenance
Pre-commit norm gate for AI-generated PRs — enforces coding and contribution norms, blocking violations before they land.
Updated 2 months ago (2026-08-18 02:17 UTC)
MIT
CodeGuardian MCP
Code Analysis Developer Tools Testing & QA Tools
codegoddy
A
license
A
quality
D
maintenance
Validates AI-generated code against actual codebases to catch hallucinations, dead code, and API mismatches before runtime.
Updated 7 months ago (2026-02-27 14:29 UTC)
12
13 npm
1
MIT
Code Impact MCP
Code Analysis Developer Tools
vk0dev
A
license
A
quality
A
maintenance
Fast pre-commit dependency gate for AI-assisted code changes. Answers "is this safe to commit?" with a PASS/WARN/BLOCK verdict in seconds, so you can catch risky blast radius before a bad commit, not after it. No database, no heavy setup.
Updated 5 days ago (2026-10-05 18:55 UTC)
5
100 npm
1
MIT
jev-harness
Agent Orchestration Autonomous Agents Testing & QA Tools
ismaelsoilet
A
license
A
quality
A
maintenance
Zero-dependency token optimizer, test-failure triage gate, and System 1.5 semantic guardrail for AI coding agents. Intercepts compiler errors, missing dependencies, and doom loops in < 500µs.
Updated 5 days ago (2026-10-06 04:51 UTC)
6
309 PyPI
11
MIT

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Server Details

Available Tools

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources