Skip to main content
Glama
ejentum

ejentum-mcp

Official

harness_code

Call before coding or reviewing code to receive an engineering scaffold that identifies failure patterns, provides correct-pattern examples, and verifies correctness.

Instructions

Call BEFORE generating, refactoring, reviewing, or debugging code. Trigger queries include: "write a function/script/class for X", "review this code/diff/PR", "refactor this", "debug this error", "is this implementation correct", "what's wrong with this code", "improve this code", "translate from X to Y language", "what would happen if I did X to this code", or any prompt that includes a code block the user wants you to act on. Also call when planning architectural changes, picking algorithms or data structures, or evaluating dependency upgrades. The tool returns an engineering scaffold (failure pattern, procedure, correct-pattern example, verification step) that you absorb internally before responding. It catches common LLM coding failure modes (hallucinated APIs, lost edge cases, premature algorithm commitment, silent contract violations, refactors that change behavior) that produce code which looks plausible but breaks under real conditions. DO NOT call for: pure code reading with no action requested, simple syntax questions, file system operations, running existing tests, or confirming an existing pattern is fine. When in doubt on non-trivial code work: call it. Pass a specific 1-2 sentence framing of WHAT you are coding or reviewing. Absorb the scaffold internally; do NOT echo bracket labels or harness vocabulary in your reply.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYes1-2 sentence framing of the task you need the harness for. Be specific about WHAT you are trying to do, not what tool you want. Good: 'diagnose why a microservice returns 503s under load'. Bad: 'help me think'.

Implementation Reference

  • The registration loop that registers all harness tools including 'harness_code' via server.tool(). The handler calls callHarness(query, harness.mode) with mode='code'.
    for (const harness of HARNESSES) {
      server.tool(
        harness.name,
        harness.description,
        querySchema,
        async ({ query }: { query: string }) => {
          try {
            const injection = await callHarness(query, harness.mode);
            return {
              content: [{ type: "text" as const, text: injection }],
            };
          } catch (err) {
            const message = err instanceof Error ? err.message : String(err);
            return {
              content: [
                { type: "text" as const, text: `Ejentum harness error: ${message}` },
              ],
              isError: true,
            };
          }
        },
      );
    }
  • Zod query schema used by all harness tools including 'harness_code'. Requires a non-empty string query describing what the user is doing.
    const querySchema = {
      query: z
        .string()
        .min(1, "query must be a non-empty string")
        .describe(
          "1-2 sentence framing of the task you need the harness for. Be specific about WHAT you are trying to do, not what tool you want. Good: 'diagnose why a microservice returns 503s under load'. Bad: 'help me think'.",
        ),
    };
  • src/index.ts:21-26 (registration)
    Tool definition entry for 'harness_code' with name, mode='code', and description. Part of the HARNESSES array used in the registration loop.
    {
      name: "harness_code",
      mode: "code",
      description:
        "Call BEFORE generating, refactoring, reviewing, or debugging code. Trigger queries include: \"write a function/script/class for X\", \"review this code/diff/PR\", \"refactor this\", \"debug this error\", \"is this implementation correct\", \"what's wrong with this code\", \"improve this code\", \"translate from X to Y language\", \"what would happen if I did X to this code\", or any prompt that includes a code block the user wants you to act on. Also call when planning architectural changes, picking algorithms or data structures, or evaluating dependency upgrades. The tool returns an engineering scaffold (failure pattern, procedure, correct-pattern example, verification step) that you absorb internally before responding. It catches common LLM coding failure modes (hallucinated APIs, lost edge cases, premature algorithm commitment, silent contract violations, refactors that change behavior) that produce code which looks plausible but breaks under real conditions. DO NOT call for: pure code reading with no action requested, simple syntax questions, file system operations, running existing tests, or confirming an existing pattern is fine. When in doubt on non-trivial code work: call it. Pass a specific 1-2 sentence framing of WHAT you are coding or reviewing. Absorb the scaffold internally; do NOT echo bracket labels or harness vocabulary in your reply.",
    },
  • The callHarness function that makes the HTTP POST to the Ejentum API with the query and mode ('code' for harness_code). Handles auth, network errors, response parsing, and field extraction using bracket notation.
    export async function callHarness(
      query: string,
      mode: HarnessMode,
    ): Promise<string> {
      const apiKey = process.env.EJENTUM_API_KEY;
      if (!apiKey || apiKey.trim().length === 0) {
        throw new Error(
          "EJENTUM_API_KEY is not set. Set it in your MCP client config (env block) and restart the client.",
        );
      }
    
      const apiUrl = process.env.EJENTUM_API_URL || DEFAULT_API_URL;
    
      let response: Response;
      try {
        response = await fetch(apiUrl, {
          method: "POST",
          headers: {
            Authorization: `Bearer ${apiKey}`,
            "Content-Type": "application/json",
          },
          body: JSON.stringify({ query, mode }),
        });
      } catch (err) {
        const detail = err instanceof Error ? err.message : String(err);
        throw new Error(`Network error calling Ejentum API at ${apiUrl}: ${detail}`);
      }
    
      if (!response.ok) {
        const body = await response.text().catch(() => "");
        if (response.status === 401) {
          throw new LogicAPIError(
            401,
            body,
            "Unauthorized (401): check your EJENTUM_API_KEY value. Get one at https://ejentum.com/dashboard.",
          );
        }
        if (response.status === 403) {
          throw new LogicAPIError(
            403,
            body,
            "Forbidden (403): your API key does not have access to this mode. Multi modes require the Haki tier.",
          );
        }
        if (response.status === 429) {
          throw new LogicAPIError(
            429,
            body,
            "Rate limit exceeded (429): you have hit your tier's request limit. See https://ejentum.com/pricing.",
          );
        }
        throw new LogicAPIError(
          response.status,
          body,
          `Ejentum API returned ${response.status}: ${body.slice(0, 200)}`,
        );
      }
    
      let parsed: unknown;
      try {
        parsed = await response.json();
      } catch {
        throw new Error("Ejentum API returned invalid JSON");
      }
    
      if (!Array.isArray(parsed) || parsed.length === 0) {
        throw new Error(
          `Ejentum API returned unexpected shape (expected non-empty array): ${JSON.stringify(parsed).slice(0, 200)}`,
        );
      }
    
      const item = parsed[0] as LogicAPIResponseItem;
    
      // Bracket access is required because the `anti-deception` field name contains a hyphen.
      // Dot access (item.anti-deception) would parse as `item.anti - deception` and silently break.
      const injection = item[mode];
    
      if (typeof injection !== "string" || injection.length === 0) {
        throw new Error(
          `Ejentum API response missing or empty "${mode}" field. Got: ${JSON.stringify(item).slice(0, 200)}`,
        );
      }
    
      return injection;
    }
  • Type definition for HarnessMode, used to type the mode parameter for harness_code ('code').
    export type HarnessMode = "reasoning" | "code" | "anti-deception" | "memory";
Behavior5/5

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

The description fully discloses what the tool does (returns an engineering scaffold), how to use it ('absorb internally, do not echo'), and why (catches common LLM coding failure modes). No annotations exist, so the description carries the full burden and meets it comprehensively.

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 lengthy but well-structured: starting with imperative call directive, followed by triggers, behavioral explanation, exclusions, and usage tips. Each sentence contributes essential information without redundancy. Could be slightly shorter, but no unnecessary fluff.

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?

For a complex tool with no output schema, the description fully explains its purpose, usage, internal behavior, and output format (failure pattern, procedure, correct-pattern example, verification step). It covers when and how to call, enabling an agent to use it correctly without additional context.

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

Parameters4/5

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

Schema coverage is 100% with one parameter 'query' described as '1-2 sentence framing.' The description adds value by clarifying specificity, providing a good example and a bad example, and emphasizing not to mention the tool. This goes beyond the schema's basic type and minLength.

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 purpose: 'Call BEFORE generating, refactoring, reviewing, or debugging code.' It provides specific trigger queries and distinguishes itself from siblings by focusing on code actions, not deception, memory, or reasoning.

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?

Explicit when-to-call and when-not-to-call instructions are given, including a list of triggers and exclusions like 'pure code reading' or 'simple syntax questions.' The phrase 'When in doubt on non-trivial code work: call it' adds decision guidance.

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

Install Server

Other Tools

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/ejentum/ejentum-mcp'

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