Skip to main content
Glama

Zephex

by io.github.Tanbir404

Structured Reasoning

keep_thinking
Read-only

Structure multi-step debugging and planning across tool calls — not a one-shot think. Tracks hypotheses, observations, plans; detects loops via lastActions; riskLevel high/critical blocks dangerous edits (drop table, prod deploy). Loads projectBrief (stack, key_paths, project_memory recall) on local project. On close, suggestedRemember → call project_memory remember. 4 credits hosted. Hard cap 10 thoughts/session. Call when: stuck after 2+ failed debug attempts, auth/billing/schema change spans 3+ files, flaky test you cannot explain, or you need a plan before editing. Pass lastActions (2–5 recent tool calls), goalAnchor after thought 2, sessionId to resume, area for subsystem. NOT when fix is known, single typo, repeating without new evidence, or session ended (nextThoughtNeeded:false). Read thoughtConfirmed and shouldContinue first. Legacy alias: thinking. Example: keep_thinking({ thought: 'Hypothesis: refresh token not rotated in middleware', thoughtType: 'hypothesis', thoughtNumber: 1, totalThoughts: 5, nextThoughtNeeded: true, confidence: 0.6, goalAnchor: 'Fix auth logout loop', lastActions: ['find_code(query=refreshToken)', 'read_code(target=authMiddleware)'], area: 'auth' }). Read-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
areaNoSubsystem (auth, billing, api) — scopes project_memory recall.
revisesNoThought number this revision replaces.
thoughtYesReasoning (20–2000 chars) — file names, symbols, error messages.
sessionIdNoResume prior session; restores checkpoint on thought 1.
confidenceYes0–1. Below 0.5 forces revision. Above 0.85 safe to proceed.
goalAnchorNoOne sentence restating the task — required after thought 2.
actionReadyNotrue when done planning and about to execute edits.
assumptionsNoUp to 5 assumptions; set invalidated:true when contradicted.
lastActionsNoLast 2–5 tool calls as name(arg=val) — identical pair triggers boredLoopDetected.
projectPathNoLocal project root (stdio defaults to cwd) for projectBrief.
thoughtTypeYeshypothesis|debug for investigation; plan|conclusion before acting.
thoughtNumberYes1-based thought index in this session.
totalThoughtsYesEstimated thoughts needed (revise upward if needed).
nextThoughtNeededYesfalse ends session and writes checkpoint.
toolOutputRelevanceNoClassify last tool result — 3+ noise/error in last 5 triggers loop.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed14 schema fields changed
    • changedInput schema / properties / actionReady / description
      Previous value: -"Set true when planning is done and you are about to execute. Produces minimal response."New value: +"true when done planning and about to execute edits."
    • changedInput schema / properties / area / description
      Previous value: -"Subsystem label (e.g. auth, api, billing) — scopes projectBrief memory recall and context focus."New value: +"Subsystem (auth, billing, api) — scopes project_memory recall."
    • changedInput schema / properties / assumptions / description
      Previous value: -"Max 5 assumptions. Mark invalidated:true when contradicted."New value: +"Up to 5 assumptions; set invalidated:true when contradicted."
    • changedInput schema / properties / goalAnchor / description
      Previous value: -"One sentence restating the original task. Required after thought 2 (two-strike rule)."New value: +"One sentence restating the task — required after thought 2."
    • changedInput schema / properties / lastActions / description
      Previous value: -"Last 2-5 tool calls as 'name(arg=val)' strings. If the last two are identical, boredLoopDetected fires. Required to detect repeated reads."New value: +"Last 2–5 tool calls as name(arg=val) — identical pair triggers boredLoopDetected."
    • changedInput schema / properties / nextThoughtNeeded / description
      Previous value: -"Set to false when reasoning is complete. Triggers checkpoint write."New value: +"false ends session and writes checkpoint."
    • changedInput schema / properties / projectPath / description
      Previous value: -"Absolute project root. Stdio: optional (uses cwd). Used to load projectBrief."New value: +"Local project root (stdio defaults to cwd) for projectBrief."
    • changedInput schema / properties / revises / description
      Previous value: -"Which thought number this revises (use with thoughtType:'revision')."New value: +"Thought number this revision replaces."
    • changedInput schema / properties / sessionId / description
      Previous value: -"Cross-session memory. Provide at thought 1 to restore last checkpoint."New value: +"Resume prior session; restores checkpoint on thought 1."
    • changedInput schema / properties / thought / description
      Previous value: -"The actual reasoning content (20–2000 chars). Be specific — include file names, function names, error messages."New value: +"Reasoning (20–2000 chars) — file names, symbols, error messages."
    • changedInput schema / properties / thoughtNumber / description
      Previous value: -"Which thought this is, 1-based"New value: +"1-based thought index in this session."
    • changedInput schema / properties / thoughtType / description
      Previous value: -"Controls compression. hypothesis/conclusion kept verbatim. observation/debug masked when old. plan/revision truncated when old."New value: +"hypothesis|debug for investigation; plan|conclusion before acting."
    • changedInput schema / properties / toolOutputRelevance / description
      Previous value: -"Classify last tool result. 3+ noise/error in last 5 triggers loop detection."New value: +"Classify last tool result — 3+ noise/error in last 5 triggers loop."
    • changedInput schema / properties / totalThoughts / description
      Previous value: -"Estimated total thoughts needed (revise upward if genuinely needed)"New value: +"Estimated thoughts needed (revise upward if needed)."
  2. Changed2 schema fields changed
    • addedInput schema / properties / area
      Added value: +{
+  "description": "Subsystem label (e.g. auth, api, billing) — scopes projectBrief memory recall and context focus.",
+  "type": "string"
+}
    • addedInput schema / properties / projectPath
      Added value: +{
+  "description": "Absolute project root. Stdio: optional (uses cwd). Used to load projectBrief.",
+  "type": "string"
+}
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

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

The description goes far beyond annotations by disclosing side effects and constraints: loop detection via lastActions, blocking dangerous edits under high risk, projectBrief loading, suggestedRemember triggering project_memory remember, credit costs, and a session cap of 10 thoughts. These are non-obvious behaviors that the agent needs to know.

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 dense and lengthy, but every sentence adds unique value. It is structured logically from purpose to behavior to usage to parameter guidance to an example. Though somewhat long, the complexity of the tool justifies the length, and the example aids comprehension.

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 15 parameters, no output schema, and rich annotations, the description covers purpose, behavior, usage conditions, and parameter semantics substantially. It references response fields like thoughtConfirmed and shouldContinue, but doesn't spell out the full response structure, which is a minor gap given 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?

While schema coverage is 100%, the description enriches parameter meaning with a concrete example and contextual notes like 'Pass lastActions (2–5 recent tool calls), goalAnchor after thought 2, sessionId to resume, area for subsystem.' This adds practical usage nuance beyond the schema's individual field descriptions.

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 opens with a specific verb and resource: 'Structure multi-step debugging and planning across tool calls.' It clearly distinguishes itself from a one-shot think and outlines concrete behaviors like tracking hypotheses and detecting loops, making the tool's unique purpose unmistakable relative to sibling tools.

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 criteria ('stuck after 2+ failed debug attempts...') and when-not-to-use conditions ('NOT when fix is known, single typo...'). This is a textbook example of usage guidance, including alternatives and exclusions.

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

All Zephex toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool targets a distinct domain: URL auditing, package checking, tests, architecture, code search, project context, planning, memory, code reading, and expert guides. Descriptions are extremely detailed and explicitly state when not to use each tool, leaving no ambiguity.

Naming Consistency4/5

Most tools follow the verb_noun snake_case pattern (audit_headers, check_package, check_test, explain_architecture, find_code, get_project_context, read_code), but project_memory (noun_noun) and Zephex_dev_info (brand_noun) deviate, and keep_thinking uses a gerund instead of a noun. The pattern is strong but not perfectly uniform.

Tool Count5/5

10 tools is well-scoped for a comprehensive development assistant. Each tool serves a clear purpose without redundancy, covering security, package management, testing, code understanding, project context, planning, memory, and expert knowledge. The count is neither too few nor excessive.

Completeness4/5

The tool surface covers a wide range of development analysis tasks: security auditing, package checking, test running, architecture mapping, code search, project context, planning, memory, code reading, and developer guides. Minor gaps include the lack of direct code editing or project execution/build tools, but the server appears intentionally focused on read-only information and planning.

Resources