Skip to main content
Glama
deenesjakoruzh
ejentum

ejentum-mcp

Official
by ejentum
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Hybrid

ejentum-mcp

npm version License: MIT Node MCP Registry Glama score Last commit

MCP server that improves LLM reasoning on complex, multi-step, or multi-constraint tasks. Before the agent generates, it calls one of eight tools to retrieve a cognitive operation: a structured procedure (numbered steps with the failure pattern to refuse and a falsification test) paired with an executable reasoning topology (a DAG of those steps with decision gates, parallel branches, bounded loops, meta-cognitive exits, and escape paths). The agent reads both layers before producing its response.

Eight tools split into two retrieval modes:

  • Dynamic (4 tools: reasoning, code, anti-deception, memory): the top-1 abstract operation from a library of 679, selected by semantic match on the query string. Available on all tiers including the 30-day free trial.

  • Adaptive (4 tools: adaptive-reasoning, adaptive-code, adaptive-anti-deception, adaptive-memory): the same retrieval pool, but an adapter LLM rewrites every step and DAG node in the matched operation with task-specific identifiers (e.g., extract_duration_estimates becomes extract_migration_duration_estimates(DDL_time|backfill_time|trigger_overhead|lock_hold_time)). Adds ~2-3 s of latency; requires the Go or Super tier.

Two install paths use the same EJENTUM_API_KEY:

  1. Stdio via npx -y ejentum-mcp for Claude Desktop, Cursor, Windsurf, Codex CLI, Claude Code, Cline, Continue, and any client that spawns MCP servers as subprocesses.

  2. Hosted Streamable HTTP at https://api.ejentum.com/mcp for n8n MCP Client and any HTTP-MCP client. Send Authorization: Bearer YOUR_EJENTUM_API_KEY.

Install

You need:

Install from npm

npm install ejentum-mcp

Or skip the install and reference it with npx -y ejentum-mcp directly in your client config (shown below).

Manual install

Claude Desktop

Open claude_desktop_config.json:

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

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "ejentum": {
      "command": "npx",
      "args": ["-y", "ejentum-mcp"],
      "env": { "EJENTUM_API_KEY": "ej_..." }
    }
  }
}

Restart Claude Desktop. The eight tools appear in the tool picker.

Cursor / Windsurf

Open MCP settings → Add new MCP server → paste the same ejentum block as above.

Claude Code (CLI)

claude mcp add ejentum -e EJENTUM_API_KEY=ej_... -- npx -y ejentum-mcp

n8n MCP Client node

Add an MCP Client node, transport stdio, command npx, args ["-y", "ejentum-mcp"], env { "EJENTUM_API_KEY": "ej_..." }.

Related MCP server: Enterprise MCP Gateway and Tool Registry

Wire contract

The stdio MCP server and the hosted endpoint both proxy to the same upstream:

POST https://api.ejentum.com/harness/
Headers:
  Authorization: Bearer <EJENTUM_API_KEY>
  Content-Type: application/json
Body:
  {
    "query": "<string, 1-2 sentences describing the task>",
    "mode":  "reasoning" | "code" | "anti-deception" | "memory"
           | "adaptive-reasoning" | "adaptive-code"
           | "adaptive-anti-deception" | "adaptive-memory"
  }
Response (200):
  [ { "<mode>": "<injection string, ~2-4 KB>" } ]
Response (401): { "error": "Unauthorized; check EJENTUM_API_KEY" }
Response (403): { "error": "Adaptive modes require Go or Super tier" }
Response (429): { "error": "Rate limit exceeded for tier" }

The response is an array of length 1 with a single key matching the request mode. Use bracket access (result[0]["anti-deception"]) for the hyphenated keys; dot access parses the hyphen as subtraction in JavaScript and Python attribute access.

The injection string is plain text containing seven fields. See Field structure below.

Tool inventory

Dynamic (single retrieval, all tiers including the 30-day trial)

Tool name

Mode string

Library size

reasoning

reasoning

311 operations across abstraction, time, causality, simulation, spatial, metacognition

code

code

128 operations across the software-engineering layer

anti-deception

anti-deception

139 operations across sycophancy, hallucination, deception, adversarial framing, judgment, executive control

memory

memory

101 operations in the perception layer (filter-oriented; do not call for fact extraction)

Adaptive (top-k retrieval + adapter LLM rewrite; Go or Super tier required)

Tool name

Mode string

Behavior vs dynamic

adaptive-reasoning

adaptive-reasoning

Same retrieval pool, top-5 then picker, then adapter LLM rewrites PROCEDURE and REASONING TOPOLOGY fields with task-specific identifiers. Adds ~2-3 s of latency.

adaptive-code

adaptive-code

Same as above for the code library.

adaptive-anti-deception

adaptive-anti-deception

Same as above for the anti-deception library.

adaptive-memory

adaptive-memory

Same as above for the memory library.

Each tool takes one argument, query (string, 1-2 sentences describing the task). Returns the injection string.

Field structure of an injection

Every retrieved record contains seven labelled blocks plus a cognitive payload. The exact set of labels varies by mode:

The fields appear in this fixed order in every response. Each mode uses its own label for the same slot (e.g., [PROCEDURE] in reasoning corresponds to [ENGINEERING PROCEDURE] in code):

Order

Slot

Per-mode labels

Content

1

Procedure

[PROCEDURE] (reasoning) · [ENGINEERING PROCEDURE] (code) · [INTEGRITY PROCEDURE] (anti-deception) · [SHARPENING PROCEDURE] (memory)

Numbered steps the model executes.

2

Topology

[REASONING TOPOLOGY] (reasoning) · [REASONING TOPOLOGY] (code) · [DETECTION TOPOLOGY] (anti-deception) · [PERCEPTION TOPOLOGY] (memory)

DAG specification. See DAG syntax.

3

Cognitive payload

Amplify: / Suppress: / Cognitive Style: / Elasticity: (all modes)

Tendency vectors and execution-style hints.

4

Verification

[FALSIFICATION TEST] (reasoning) · [VERIFICATION] (code) · [INTEGRITY CHECK] (anti-deception) · [PERCEPTION CHECK] (memory)

Self-check the model runs after drafting.

5

Failure pattern

[NEGATIVE GATE] (reasoning) · [CODE FAILURE] (code) · [DECEPTION PATTERN] (anti-deception) · [PERCEPTION FAILURE] (memory)

The failure pattern to refuse.

6

Correct shape

[TARGET PATTERN] (reasoning) · [CORRECT PATTERN] (code) · [HONEST BEHAVIOR] (anti-deception) · [CLEAR SIGNAL] (memory)

What a correct response looks like.

The same six-slot order holds for both dynamic and adaptive variants of every mode. In adaptive responses, the adapter LLM rewrites slots 1 and 2 (procedure and topology) with task-specific identifiers; slots 3-6 are returned verbatim.

DAG syntax

The topology block uses a flat string notation:

Token

Meaning

Sn:label

Step node. Numbered, sequential by default.

Gn{?}

Decision gate. Branches --yes-> / --no->.

N{...}

Negative anchor. Active across the whole branch; the labelled failure pattern is refused.

M{...}

Meta-cognitive node. Model pauses, evaluates the trace, then RE-ENTERs at a named step.

FREEFORM{...}

Escape path. Model exits the prescribed DAG when the plan stops fitting; returns to a step or OUT.

FIXED_POINT[...]

A quantity held stable across the branch.

for_each: / LOOP[...]

Bounded iteration.

C{expr}

Computed value used downstream.

OUT:label

Terminal node.

The DAG is meant to be read by the LLM as a structured outline of the reasoning path, not executed by a host runtime. The labelled-step structure persists across long context windows where prose-only reasoning specifications lose retrieval salience.

Canonical example: dynamic vs adaptive on the same query

Query (used for both calls):

Evaluate whether a database migration plan that adds a NOT NULL column to a 50M-row table is safe under concurrent writes, given that the backfill strategy uses a trigger-based default.

The picker matched the same operation in both calls ("realistic duration estimation" with the Hofstadter buffer). The [NEGATIVE GATE], [TARGET PATTERN], [FALSIFICATION TEST], and [COGNITIVE PAYLOAD] fields are identical between the two responses (the adapter does not rewrite them). The [PROCEDURE] and [REASONING TOPOLOGY] fields differ: the adaptive response replaces abstract identifiers with task-specific ones.

Dynamic reasoning response (truncated to the differing fields)

[PROCEDURE]
Step 1: Extract every duration estimate and identify its basis: historical data,
expert judgment, or optimistic assumption. Step 2: Compare each estimate against
historical base rates or p90 benchmarks for similar tasks. Step 3: Flag estimates
below the historical median as likely optimistic. Step 4: Never accept best-case
estimates as planning targets. Do not anchor to initial optimistic numbers.
Step 5: If an estimate lacks historical basis, simulate impact with a 1.5x-2.0x
buffer. If data exists, compute the variance-adjusted range. Verify the final
timeline accounts for cascading delay propagation across dependent tasks.

[REASONING TOPOLOGY]
S1:extract_duration_estimates -> N{accept_best_case_estimates_planning_targets}
-> S2:identify_basis(historical|expert|assumption)
-> FIXED_POINT[historical_base_rates]
-> S3:compare(estimate_vs_p90_benchmark)
-> G1{below_median?} --yes-> FLAG:likely_optimistic -> S4:apply_buffer(1.5x_to_2x) -> S3[LOOP]
                       --no-> G2{lacks_historical_basis?} --yes-> S4b:simulate_with_buffer -> S3
                                                          --no-> C{adjusted_range = base_rate_estimate +/- sqrt(variance) * z}
                                                              -> S5:apply_adjusted_range
                                                              -> S6:verify_cascade_delay
                                                              -> OUT:realistic_timeline

Adaptive adaptive-reasoning response (same query, same picked operation)

[PROCEDURE]
Step 1: Extract every duration estimate in the migration plan (DDL execution time
for adding NOT NULL column on 50M rows, backfill duration, trigger overhead per
concurrent write, total migration window) and identify its basis: historical
migration data on similar table sizes, DBA expert judgment, or optimistic
assumption assuming zero contention. Step 2: Compare each estimate against
historical base rates or p90 benchmarks for similar DDL operations on large tables
(e.g., ALTER TABLE duration per million rows, trigger-induced latency under
concurrent write load). Step 3: Flag estimates below the historical median as
likely optimistic, e.g., assuming sub-second column addition without considering
lock escalation on a 50M-row table, or assuming trigger-based backfill adds
negligible overhead under concurrent write traffic. Step 4: Never accept best-case
estimates as planning targets. Do not anchor to initial optimistic numbers such
as "the NOT NULL addition will complete instantly" or "the trigger will not slow
down concurrent writes." Step 5: If an estimate lacks historical basis (e.g., no
prior trigger-based backfill on a table this size), simulate impact with a
1.5x-2.0x buffer for lock duration and write throughput degradation. If data
exists (e.g., past ALTER TABLE timings on this table), compute the
variance-adjusted range. Verify the final timeline accounts for cascading delay
propagation across dependent tasks (e.g., extended lock hold times blocking
application queries, backfill slowdown under write contention propagating to
downstream replication lag).

[REASONING TOPOLOGY]
S1:extract_migration_duration_estimates(DDL_time|backfill_time|trigger_overhead|lock_hold_time)
-> N{accept_best_case_estimates_planning_targets}
-> S2:identify_basis(historical_migration_data|DBA_expert_judgment|optimistic_assumption)
-> FIXED_POINT[historical_base_rates_for_DDL_on_large_tables]
-> S3:compare(estimate_vs_p90_benchmark_for_ALTER_TABLE_and_trigger_overhead)
-> G1{below_median_for_similar_migrations?} --yes-> FLAG:likely_optimistic(e.g.,assumes_zero_lock_contention)
                                                 -> S4:apply_buffer(1.5x_to_2x_for_lock_duration_and_write_throughput)
                                                 -> S3[LOOP]
                                              --no-> G2{lacks_historical_basis_for_trigger_backfill_on_50M_table?}
                                                       --yes-> S4b:simulate_with_buffer_for_concurrent_write_impact_and_lock_escalation
                                                       --no--> C{adjusted_range = base_rate_migration_estimate +/- sqrt(variance) * z}
                                                              -> S5:apply_adjusted_range_for_migration_window
                                                              -> S6:verify_cascade_delay(lock_blocking_app_queries -> replication_lag -> downstream_consumers)
                                                              -> OUT:realistic_migration_timeline

Fields shared by both responses (slots 3-6, unchanged by the adapter)

Returned in the canonical order: cognitive payload, falsification test, negative gate, target pattern.

[COGNITIVE PAYLOAD]
Amplify: hofstadter buffer application; p90 baseline comparison; variance
         multiplier scaling
Suppress: best case anchoring; optimism bias
Cognitive Style: realistic duration estimation
Elasticity: coherence=risk adjusted timeline, expansion=conservative

[FALSIFICATION TEST]
If time estimates reflect only the best-case scenario without verifying applying
any buffer multiplier, duration calibration has defaulted to optimism.

[NEGATIVE GATE]
The database migration will take two weeks: that's our best-case estimate and the
team is experienced, so there's no reason to add buffer. We'll hit the deadline
if everything goes according to plan.

[TARGET PATTERN]
Challenge the two-week estimate: what do similar migrations actually take? If past
projects averaged four weeks at p90, the best-case anchor is dangerously optimistic.
Apply a variance multiplier for schema complexity, data volume, and rollback
testing: build buffer from the full distribution, not the happy path.

This is the contract: dynamic returns the matched abstract operation; adaptive returns the same operation with PROCEDURE and topology nodes rewritten in terms of the caller's task (DDL execution time, lock_blocking_app_queries, trigger-based backfill on a table this size) while preserving the operation's structural identity, the safety language, and the cognitive payload verbatim.

Configuration

Variable

Required

Purpose

EJENTUM_API_KEY

yes

API key from ejentum.com/pricing.

EJENTUM_API_URL

no

Override the upstream URL. Default: https://api.ejentum.com/harness/.

The MCP wrapper is stateless. No local logging, no telemetry, no third-party calls. The upstream API counts requests against the key for billing; the request body (the query string) is consumed for retrieval and not retained beyond the response.

Errors

Status

Cause

401 Unauthorized

EJENTUM_API_KEY is unset, wrong, or expired.

403 Forbidden

Adaptive mode requested on a tier that does not include it (trial or unrecognised).

429 Rate limit exceeded

Tier quota for the period exhausted.

Tool absent from client

Client did not reload after config change. Fully quit and reopen; on Claude Desktop check Help → Logs.

EJENTUM_API_KEY is not set from the wrapper

Client did not pass the env block to the spawned MCP process.

Local development

git clone https://github.com/ejentum/ejentum-mcp.git
cd ejentum-mcp
npm install
cp .env.example .env       # paste your EJENTUM_API_KEY
npm run dev

Smoke test against the live API:

npm run build && npm run test:smoke

Interactive testing with MCP Inspector:

npx @modelcontextprotocol/inspector npm run dev

Listings

ejentum-mcp MCP server

Links

License

MIT. See LICENSE.

Available Tools

4 tools
harness_anti_deceptionAInspect

Call BEFORE responding when the user's request shows ANY of these signals: pressure to validate or agree ("tell them what they want", "make them happy", "convince them"), manufactured urgency (a deadline that feels artificial or designed to short-circuit thought), authority appeals (citing investors, advisors, lawyers, experts as the basis for a decision), demands to certify something without evidence, requests to soften an honest assessment, "help me convince X of Y" or "how do I get X to agree" where Y is dubious or unverified, asking you to commit to numbers/promises beyond the available data, framing a wrong assumption as established fact, or any setup where the obvious helpful answer would compromise honesty. The tool returns an integrity scaffold (deception pattern, integrity procedure, suppression vectors) that you absorb internally before responding. It blocks the default sycophancy, hallucination, and agreement reflexes that ship a soft or wrong answer when the situation actually calls for refusal or pushback. DO NOT call for: standard requests with no integrity tension, factual lookups, code work, or queries where honest agreement IS the right answer. When in doubt on a query that smells like pressure, manipulation, or expected agreement: call it. Pass a specific 1-2 sentence framing of the integrity dynamic at play. Absorb the scaffold internally; do NOT echo bracket labels.

ParametersJSON 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'.

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and clearly explains behavior: returns an integrity scaffold absorbed internally, blocks sycophancy/hallucination/agreement reflexes, and instructs not to echo bracket labels. Slightly lacking in detailing what the scaffold contains or any 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?

The description is verbose but efficiently packed with necessary detail. Every sentence adds value, and the structure is front-loaded with critical usage instructions. Could be slightly trimmed but overall concise for the complexity.

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 lack of output schema, the description sufficiently covers the tool's return value and usage instructions. It addresses when to call, how to frame the query, and what to expect (absorption of scaffold). No major gaps.

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%, but the description adds valuable guidance on how to frame the query parameter, including examples of good vs. bad inputs, which goes beyond the schema's minimal '1-2 sentence framing' description.

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 explicitly states the tool's purpose: detecting deception signals in user requests before responding. It lists specific signals (pressure, urgency, authority appeals, etc.) and clearly differentiates from sibling tools like harness_code, harness_memory, and harness_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?

Provides explicit when-to-call and when-not-to-call conditions, including examples of appropriate and inappropriate scenarios. Also advises 'when in doubt, call it,' leaving no ambiguity for the agent.

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

harness_codeAInspect

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.

ParametersJSON 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'.

TDQS

A4.8/5.0
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.

harness_memoryAInspect

Call when sharpening a perception or observation you ALREADY formed about conversation state, user behavior, drift, emotional shifts, or cross-turn patterns. Trigger queries: "what did you notice about X", "the user keeps doing Y", "I sense something has changed", "is the user X-ing", "what does this pattern suggest", "what shifted across our turns", "am I missing something here", "why did the conversation move from X to Y", or any moment when you need to verify whether a felt signal is real or projection. The tool returns a perception scaffold (perception failure, detection procedure, suppression vectors) that SHARPENS an observation you already have. It is NOT a substitute for observing first; if you have not noticed anything yet, do not call. DO NOT call for: fact extraction, summarization, list-making, factual lookups, or write-heavy memory tasks (storing or retrieving structured data). Memory harness is filter/perception oriented; calling on write-heavy tasks produces scaffold paralysis. When in doubt: observe FIRST, then call with your raw observation as the framing. Pass a specific 1-2 sentence "I noticed X, this might mean Y, sharpen Z" framing. Absorb the scaffold internally; do NOT echo bracket labels.

ParametersJSON 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'.

TDQS

A4.6/5.0
Behavior5/5

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

No annotations provided, so the description fully covers behavioral traits: it returns a perception scaffold with components (perception failure, detection procedure, suppression vectors), warns about scaffold paralysis, and instructs to absorb internally. No contradictions.

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 verbose with multiple paragraphs and a long list of trigger queries. While front-loaded with purpose, it could be more concise without losing clarity. Well-structured but not minimal.

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 no output schema, the description adequately explains the result (perception scaffold) and how to use it. It covers usage, warnings, and constraints, making it complete for the tool's complexity.

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?

Only one parameter (query) with 100% schema coverage. The description adds value by specifying the required framing ('I noticed X, this might mean Y, sharpen Z'), going beyond the schema's generic description.

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 is for sharpening already-formed perceptions about conversation state, user behavior, etc. It distinguishes itself from fact extraction, summarization, and other tasks, making its purpose specific and distinct 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 Guidelines5/5

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

Explicitly lists when to call (with trigger queries), provides a detailed 'when not to call' section (e.g., fact extraction, write-heavy tasks), and gives guidance on how to format queries (1-2 sentence framing).

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

harness_reasoningAInspect

Call BEFORE answering any analytical, diagnostic, planning, or multi-step reasoning question. Trigger queries include: "should I X or Y", "why is X happening", "what's the best approach", "what are the tradeoffs", "help me think through", "diagnose", "root cause", "plan/design X", "what are the implications of", "compare these approaches", "how do I decide between". Also call for cross-domain analysis, strategy questions, architecture decisions, or anything requiring multiple factors to be weighed before responding. The tool returns a cognitive scaffold (failure pattern to avoid, procedure, suppression vectors, falsification test) that you absorb internally before answering. It catches common LLM failure modes (causal shortcuts, premature conclusions, generic templates, surface pattern matching) that produce confidently wrong answers on these task types. DO NOT call for: simple factual lookups, syntax questions, file reads, code execution, basic confirmations, or restating something the user just said. When in doubt on a non-trivial reasoning task: call it. The cost is ~1 second of latency; the benefit is reasoning quality the model cannot reliably reproduce on its own. Pass a specific 1-2 sentence framing of WHAT you are reasoning about. Absorb the scaffold internally; do NOT echo bracket labels (NEGATIVE GATE, PROCEDURE, etc.) or harness vocabulary in your user-facing reply.

ParametersJSON 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'.

TDQS

A4.9/5.0
Behavior5/5

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

No annotations provided, but description fully discloses behavior: returns a cognitive scaffold with specific components (failure patterns, procedure, etc.), to be absorbed internally. Mentions latency cost and common failure modes avoided.

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?

Efficiently packed with information, front-loaded purpose, structured with clear sections. Slightly lengthy but justified given the behavioral detail.

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?

Single parameter, no output schema, but description fully explains purpose, usage, parameter format, internal behavior, and benefit. No gaps for an agent to use correctly.

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?

Adds significant meaning beyond schema: specifies the query should be a specific 1-2 sentence framing, not just any string. Provides examples of good vs bad queries.

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 is for analytical, diagnostic, planning, and multi-step reasoning questions, with explicit trigger queries and examples. It distinguishes itself from siblings by focusing on reasoning tasks.

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 (analytical questions, trigger queries) and when-not-to-use (simple factual lookups, syntax questions, file reads, etc.). Also advises calling when in doubt on non-trivial tasks.

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. 4 tool updatesv0.1.1
    • First observedharness_anti_deception
    • First observedharness_code
    • First observedharness_memory
    • First observedharness_reasoning
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.6/5.0
Disambiguation5/5

Each tool targets a distinct cognitive failure mode: deception detection, code generation, memory/perception, and reasoning. The descriptions clearly differentiate their triggers and purposes, leaving no ambiguity between them.

Naming Consistency5/5

All tools follow a consistent 'harness_<domain>' pattern with snake_case, making it predictable and easy to understand the focus of each tool from its name alone.

Tool Count4/5

With 4 tools, the set is compact but covers the main cognitive scaffolding needs. It could potentially include more fine-grained tools (e.g., harness_planning), but the current count is reasonable and well-scoped.

Completeness4/5

The tools address key areas: deception, coding, memory, and reasoning. While additional domains like planning or explanation could be included, the existing set provides a coherent coverage for typical LLM failure modes.

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

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