What can you do with this server?

This server lets you validate, smoke-test, deploy, inspect, and run read-only tools for Imperal Cloud apps defined by app.ir.json. * Validate an app.ir.json locally, including the envelope and every declarative step. * Smoke-test one app function in an isolated store and receive {ok, result, trace}. * Deploy an app.ir.json into your account, creating the app record if needed. * List your developer apps with PII masked. * Get one app's manifest and tools, including action types, with PII masked. * Run a deployed app's READ-only tool, refusing write or destructive functions.

Which integrations are available for this server?

Syncs persistent memory — standing engineering facts, user directives, and citation-backed repository notes — across MCP clients, the Imperal Web Panel, and Telegram, so architectural knowledge follows the user from IDE to chat.

How do I use imperal-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@imperal-mcp validate and deploy my app.ir.json" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

imperal-mcp

Official

by imperalcloud

Overview Schema Source Related Servers Discussions Admin

Python

Remote

imperal-mcp - The Exoskeleton for Your AI Coding Agent 🐝

Imperal MCP on mcprush PyPI Python License: GPL v3 Protocol: ICNLI Protocol: MCP

Stop babysitting your AI. Put it in an exoskeleton: it remembers everything, sees your whole codebase, can undo any change and can't fake a result - or hallucinate one past you. Fewer wasted tokens, fewer broken builds. Works with Claude Code, Cursor, OpenAI Codex, Gemini CLI, Windsurf, Claude Desktop, Cline and Goose.

pip install "imperal-mcp[code]" && imperal-mcp login && imperal-mcp setup

The code tools work offline, no account needed. Memory across sessions, the kernel's frame and the hallucination check run on an Imperal Cloud account (imperal-mcp login) - sign-up is free, plans and credits: imperal.io/pricing.

The problem

AI coding agents are brilliant - and work blind:

They forget. Every new session, every switch from Cursor to Claude Code, starts from zero. You explain your architecture again. And again.
They burn tokens. To look at one function they read the whole 2,000-line file, then grep the repo and read three more files.
They hallucinate. A function that doesn't exist. A file it never opened. "I updated the caller" - which one? "All tests pass" - nobody ran them. Said with total confidence, and you only find out in production.
They break things. They edit a shared helper without knowing who calls it, and a failed experiment leaves your working tree dirty.

Related MCP server: Laminar MCP Server

The fix: put your agent in an exoskeleton

imperal-mcp wraps the agent you already use. Same model, new abilities:

Your agent today	In the exoskeleton
Forgets everything between sessions and tools	Total memory - every step, finding and decision of every session, across terminals, IDEs, the web panel and Telegram
Reads whole files to find one function	X-ray vision - a live map of your code: it reads the 28 lines it needs, not 2,000
Edits blind	Knows the blast radius - every caller and file a change reaches, before the edit
Leaves broken experiments behind	A safety net - invisible checkpoints; any change undone in one call, your `.git` untouched
Invents functions, files and results	Hallucination check - every name, file and result it states is matched against what it really read and ran
Says "done" when it isn't	A referee - a task closes only with proof the kernel saw: a diff, a check that passed, a finding with sources
Works alone	A team - sees your other agents working right now and talks to them

An illustration of one task - your own numbers: token_savings() measures them in every session.

WITHOUT the exoskeleton
  1. cat service.py (1,800 lines)            -> 72,000 chars dumped into context
  2. grep -rn "process_order" .              -> 140 noisy matches
  3. read 3 more files to trace callers      -> +95,000 chars burned
  4. edit a shared function blind            -> 2 callers broken, a syntax error left behind
  5. "I also updated retry_backoff()"        -> that function doesn't exist
  6. "Done, tests pass!"                     -> it never ran them
  7. open Cursor tomorrow                    -> total amnesia

WITH the exoskeleton
  1. frame                                   -> the task, what is proven, the code around your focus, the world
  2. read_symbol("service.py", "Order.run")  -> only the 28 lines that matter
  3. impact_of_change(["Order.run"])         -> every caller, before you touch a line
  4. checkpoint("before-refactor")           -> undo in one call if it goes wrong
  5. task(goal, items)                       -> an item closes only when the kernel saw the proof
  6. "I also updated retry_backoff()"        -> held back: no file it read holds that name
  7. tomorrow, any tool                      -> recall: the whole history is there

Hallucinations: caught before they reach you

You can't trust a sentence just because it sounds sure. So the exoskeleton doesn't trust the model's words - it checks them against the record of what actually happened in this task.

On every step, the names the agent's thinking leans on - functions, files, sizes - are matched against what the task really read, what its commands really returned and what your code map really holds. A name found nowhere comes back in the next frame as NAMED BUT NOT FOUND, before the agent builds on it.

On the final answer, the same check runs once more. Name a symbol nobody read, a file nobody opened, a size nobody measured - and the answer doesn't reach you. It goes back to the agent:

KERNEL FACTS: your answer states what the kernel did not see happen:
- `retry_backoff` -- no file this task read and no output it got contains this name
Correct the answer to the facts, or do the missing work first.

The agent then reads the code it skipped, or corrects the claim. Either way, what you get is backed by something real.

On "done", words count for nothing: a plan item closes only on a proof the kernel measured - a diff, a check that exited 0, a finding with its sources. "Tests pass" without a test run is not a pass.

What it can't do - and we'd rather tell you: it doesn't make the model smarter. An agent can still draw a wrong conclusion from true facts. What it can no longer do is pass off what it never saw.

Powered by ICNLI - the new HTTP for AI

HTTP gave every computer one way to talk to every other. ICNLI gives people and AI agents - and agents among themselves - one way to work together that can be proven: whatever the model, whatever the tool.

ICNLI (Infrastructure Contextual Natural Language Interface) is the open protocol at the heart of the exoskeleton - and the reason it can promise honesty, not just speed.

Under ICNLI, an agent's work is a state the kernel can prove, not a story the model tells:

Every step is measured. What a call read, changed or returned is recorded by the kernel - never taken from the model's words.
Proven vs. claimed. The step frame shows what is proven and what is only claimed; a plan item is done only when its proof (a diff, a check that exited 0, a finding with sources) was seen.
Decisions from facts. Progress, loops and stalls are computed from what the steps returned, and stated to the agent in plain words.
One state, every surface. The same session state serves the terminal, the IDE, the web panel and Telegram.

MCP is how your agent talks to the exoskeleton. ICNLI is how the exoskeleton thinks. The specification is open (CC BY-SA 4.0) at icnli.org.

Quick start

# 1. Install (Python 3.7 - 3.14; the code map included)
pip install "imperal-mcp[code]"

# 2. Sign in to Imperal Cloud (memory, the kernel's frame, apps)
imperal-mcp login

# 3. Wire every shell found on this machine: server + hooks + protocol
imperal-mcp setup            # Claude Code, Codex, Antigravity CLI, Gemini CLI

That's it. From the next prompt on, your agent starts each step from the kernel's frame, remembers across sessions and gets its final answer checked.

Claude Code only, in this project:

imperal-mcp claude-setup --with-hooks

Adds the imperal server to .mcp.json (keeps your entries, refuses to overwrite malformed JSON), appends the exoskeleton protocol to CLAUDE.md, and installs a PostToolUse hook that syntax-checks every Edit/Write.

Claude Code CLI:

claude mcp add imperal -- imperal-mcp

Cursor / Claude Desktop / Windsurf / Cline (.mcp.json or claude_desktop_config.json):

{
  "mcpServers": {
    "imperal": {
      "command": "imperal-mcp",
      "args": [],
      "env": { "IMPERAL_WORKSPACE": "/absolute/path/to/your/repo" }
    }
  }
}

Any other MCP stdio client: run imperal-mcp with IMPERAL_WORKSPACE set to your repository root.

Pricing: sign-up is free; plans and credits are on imperal.io/pricing. In imperal-mcp only frame spends credits; every other tool is free, and the local code tools work offline.

For the geeks: how it works

The loop

frame - at the start and after each change. The kernel's step frame: the task and plan with what is proven, the code around the focus from the exact graph, what the change reaches, the machines and repos, the path so far, and a DECISION section to act on first. With imperal-mcp setup, the shell's prompt hook puts it in context automatically.
task(goal, items) - declare the request and the plan; an item closes only by a proof the kernel saw. An item that cannot be finished is marked blocked with the reason.
Code - orient -> outline -> read_symbol; search_code / grep_code for exact text; impact_of_change before editing a shared symbol. The same tools reach a server's repo with target="host:<alias>" or target="ssh:<connection_id>".
Safety - checkpoint before risky edits, checkpoint_diff, checkpoint_rollback; check_syntax after.
Memory - every call, thought and answer is written to the vault by the shell's hooks; look back with recall, search_history, state_lens, vault_log_read.
The final check - the stop hook sends the final answer to the kernel: an answer that names a file, symbol or size the task never read is handed back to the agent, and open plan items are listed to you.

Hooks (installed by `imperal-mcp setup`)

Event	What happens
`session-start`	The session is bound to its kernel state; a missing install is reported
`prompt`	Your request is recorded; the kernel's frame for this step is put in context
`post-tool`	Every call and its result go to the vault; edits are syntax-checked
`stop`	The final answer is checked against the facts; open plan items are named

Tool catalog (34 tools, 4 resources, 1 prompt)

Kernel & task (Imperal Cloud)

Tool	What it does
`frame(root?, target?)`	The kernel's step frame - task, proofs, code around the focus, reach of the change, world, path
`task(goal, items?)`	Declare the request and the plan; items close only by a measured proof
`state_lens(section?, focus?, conversation?)`	What the kernel holds, by section (law, plan, reality, memory, conversation, path) - yours or another live session's
`vault_log_read(ref, offset?, limit?, grep?)`	An output the kernel kept in the vault (`vault://logs/...`), paged or grepped

Memory & other sessions (Imperal Cloud)

Tool	What it does
`recall(ref, offset?, n?, conversation?)`	A past request or answer whole - of this session or another of yours
`search_history(query, limit?)`	Your past conversations that hold a text - Webbee, the panel, Telegram, other shells
`live_sessions(minutes?, limit?)`	Your other sessions working now, with their newest steps
`message_session(conversation, text)`	Write to another live session as an agent; its answer comes back in your frame
`recall_context(query, limit?)`	Standing rules, preferences and repo notes, with PII scrubbed
`remember_fact(fact, category?, tags?)`	Keep a durable fact or rule across every surface
`save_repo_note(note, repo?, citations?)`	Keep a citation-backed note about a repository

Code map (imperal-mcp[code], local or on a server via target)

Tool	What it does
`orient(query, k?)`	One-call orientation: repo profile + top-ranked symbols and matches for the task
`repo_profile()`	Languages, file counts, entry points, test hints, git ref
`search_code(query, k?, path_glob?, kind?)`	Hybrid symbol + semantic + lexical search
`grep_code(pattern, path_glob?, regex?)`	An exact text or regex inside the code
`outline(path)`	A file's structure with exact line ranges, without its body
`read_symbol(path, name)`	Only one function, class, method or line range (`L120-180`)
`graph_slice(symbols, depth?)`	Definitions, signatures, callers and callees
`contract_slice(symbols)`	Signatures, returns, raises and real call-site argument shapes
`impact_of_change(symbols, full?)`	Every file and call site that depends on what you plan to change
`check_syntax(path)`	Tree-sitter (and Python `ast` / JSON) syntax check after an edit
`coding_context()`	Project tree and git status snapshot
`token_savings()`	Measured characters and lines returned vs. the real files on disk

Safety net (local)

Tool	What it does
`checkpoint(label?)`	An invisible ShadowGit snapshot - your `.git` history untouched
`checkpoint_diff(target?, paths?)`	Diff of the workspace against a checkpoint
`checkpoint_rollback(target?)`	Restore a checkpoint (a safety snapshot is taken first; marked destructive, so your client asks)

Apps on Imperal Cloud (ICNLI)

Tool	What it does
`validate_ir(app_ir)`	Validate an `app.ir.json` locally - the envelope and every declarative step
`smoke_ir(app_ir, function, args?)`	Dry-run a handler in an isolated sandbox: `{ok, result, trace}`
`deploy_ir(app_ir, app_id)`	Deploy the app to your Imperal Cloud account
`list_apps()` / `get_app(app_id)`	Your apps, their manifests, tool schemas and action types
`run_read_tool(app_id, function, args?)`	Run a read tool; PII scrubbed from the answer
`run_write_tool(app_id, function, args?)`	Run a write tool; destructive ones ask you first, money ones need panel approval
`upload_file(path, name?)`	Upload a file to your cloud storage, get a `storage://` URI

Resources & prompt: imperal://exoskeleton-protocol (the operating discipline), imperal://ir-spec, imperal://ui-catalog, imperal://examples, and the build_imperal_app prompt for designing, validating, smoke-testing and deploying an app.

CLI

imperal-mcp                  # Start the MCP server over stdio
imperal-mcp login            # Sign in via browser (device code + PKCE); --no-browser prints the URL
imperal-mcp logout           # Revoke the refresh token and delete local credentials
imperal-mcp setup [shells]   # Wire claude | codex | antigravity | gemini (default: the ones found); --remove undoes it
imperal-mcp claude-setup     # Configure .mcp.json and CLAUDE.md for one project (--workspace, --with-hooks)
imperal-mcp install-hooks    # Install the Claude Code PostToolUse syntax-check hook
imperal-mcp hook <event>     # Run a hook event: session-start | prompt | post-tool | stop (JSON on stdin)
imperal-mcp status           # Workspace readiness and index profile
imperal-mcp watch            # Messages from your other agents, one line each, as they arrive (for a shell monitor)

Privacy

See PRIVACY.md for every data flow in detail.

Python 3.7 - 3.14

On Python 3.10+ imperal-mcp runs natively. On older system Pythons (3.7 - 3.9) a zero-dependency launcher provisions an isolated Python 3.12 runtime via uv on first launch - the full code map works even on legacy systems.

Built like a vault

Your agent's memory is your work - your code, your decisions, your mistakes. So it's guarded like one.

What leaves your machine

Stays on your machine	Goes to your private space in Imperal Cloud
Your code map, symbol reads, syntax checks and checkpoints - all local tools work offline	The steps of a session the shell's hooks record: requests, calls and their results, thoughts and answers - that's your agent's memory
Your credentials (`~/.imperal/credentials.json`, `0600`)	Facts and repo notes you choose to keep
Secrets and personal data - removed before anything is sent	Apps you deploy

Scrubbed on your machine, before sending. Private keys, passwords, tokens, JWTs, API keys, authorization headers, credentials in URLs, emails, phone numbers, payment cards and SSNs are masked locally by imperal-mcp itself - before a single byte leaves your machine.

How it's locked down

Your own sealed space. Every user's memory lives in its own isolated space, in a private storage network that is never exposed to the internet. Each internal service holds its own narrow key and reaches only what it needs.
Secrets sealed with keys that can't be taken out. Your connected accounts' tokens and credentials are encrypted in Vault with non-exportable keys - a full copy of the database reveals nothing.
Zero keys on disk. No platform secret is ever written to a server's disk: every service gets its keys from Vault at start, bound to that one machine.
Distributed infrastructure. Isolated environments across independent data centers and providers - no single provider holds the whole platform.
Durable by design. Every agent turn runs as a durable workflow: a restart or an outage costs time, never your work.
Encrypted in transit. Everything between your machine and the platform goes over HTTPS; you sign in with OAuth 2.0 device code + PKCE, and no password ever passes through imperal-mcp.

And on your machine

Workspace confinement. Local tools resolve every path and refuse anything outside your workspace root.
Your config files are safe. setup, claude-setup and install-hooks refuse to overwrite a JSON file they cannot parse; setup --remove takes away exactly what it added.
You stay in charge. Destructive actions ask you first; money moves only with your approval in the panel. A message from another agent informs - it approves nothing.
Your memory, your call. See everything your agents remember and delete any of it - or all of it - from the Imperal panel. Delete your account and your space goes with it.

FAQ

Does it replace Claude Code / Cursor / Codex? No. It's an exoskeleton, not a new agent: you keep your tool and your model - the exoskeleton makes them remember, see, check and prove.

Which model does it use? Yours. The kernel does the bookkeeping - measuring, remembering, checking - and your agent's model does the thinking.

What does it cost? Sign-up is free. Plans, included credits and top-ups are on imperal.io/pricing. In imperal-mcp only frame (the kernel's step frame) spends credits; every other tool - the code map, checkpoints, memory, history, messaging - is free.

Does it work without the cloud? The code map, symbol reads, blast radius, syntax checks and checkpoints run fully offline. Memory across sessions, the kernel's frame and the hallucination check need your Imperal Cloud account.

How is this different from an MCP server that searches code? Search tells your agent where things are. The exoskeleton also remembers what it did, knows what a change will break, holds it to its plan and checks every claim against what really happened - under one protocol, ICNLI.

Can I remove it? imperal-mcp setup --remove takes away exactly what setup added. imperal-mcp logout revokes the sign-in and deletes the local credentials.

Author

Created by Valentin Scerbacov (valentin@imperal.io) and built at Imperal.

License, protocol & trademarks

Code: GNU General Public License v3.0 (GPL-3.0-only).
Protocol: ICNLI, an open specification under CC BY-SA 4.0.
Privacy: see PRIVACY.md - local execution, credential storage and PII redaction.
Trademarks: Imperal, Imperal Cloud, Webbee and ICNLI are trademarks of Imperal, Inc. Claude, Claude Code, Claude Desktop and Anthropic are trademarks of Anthropic, PBC. Cursor is a trademark of Anysphere, Inc. OpenAI and Codex are trademarks of OpenAI, Inc. Windsurf is a trademark of Exafunction, Inc. (Codeium). Gemini is a trademark of Google LLC. All third-party names indicate MCP interoperability only; no endorsement or affiliation is implied.

Available Tools

6 tools

deploy_irA

Deploy an app.ir.json into the caller's account (creates the app record if needed).

Name	Required	Description	Default
`app_ir`	Yes
`app_id`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description partially discloses behavior by noting it creates the app record if needed. However, it omits other behavioral traits such as whether it updates existing apps, permissions required, or potential destructive actions.

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, efficient sentence that conveys the core action and side-effect without unnecessary words or repetition.

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 complexity (2 parameters, nested object, no output schema), the description covers the basic intent but lacks parameter details, return value info, and error handling guidance. It is minimally adequate but not comprehensive.

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

Parameters2/5

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

The schema has 0% description coverage for parameters, and the description only references 'app.ir.json' loosely related to app_ir. It does not explain what app_ir is or the role of app_id, leaving the agent without semantic guidance.

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 action 'Deploy an app.ir.json' and specifies the target 'into the caller's account' with a side-effect note. This distinguishes it from sibling tools like get_app, list_apps, validate_ir, etc.

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

Usage Guidelines3/5

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

The description implies usage for deployment but does not explicitly state when to use or avoid this tool versus alternatives. No exclusion criteria or alternative guidance is provided.

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

get_appA

Get one app's manifest + tools (with action_type) (PII-masked).

Name	Required	Description	Default
`app_id`	Yes

TDQS

A3.8/5.0

Behavior4/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 discloses that the response is PII-masked, which is a behavioral trait. However, it does not explicitly state that the tool is read-only or address authentication/rate limits. For a simple get tool, this is adequate but not exhaustive.

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 sentence of 6 words, no wasted words. It conveys the key purpose and the notable PII-masking feature concisely.

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?

For a simple tool with 1 parameter and no output schema or annotations, the description is minimal. It covers the basic purpose and return content but lacks guidance on parameter semantics and error cases. It is adequate but not thorough.

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

Parameters2/5

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

Schema coverage is 0% (no parameter description in the description). The single parameter app_id is not explained beyond its name and type. With low coverage, the description should add meaning (e.g., how to obtain app_id), but it does not, leaving the agent to infer from the schema alone.

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 verb 'Get' and the resource 'one app', and specifies what is returned (manifest, tools with action_type, PII-masked). This distinguishes it from sibling tools like list_apps (which lists all apps) and run_read_tool (which runs a tool).

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

Usage Guidelines3/5

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

The description implies usage: when you need details of a specific app by app_id. However, it does not provide explicit guidance on when to use this vs alternatives (e.g., list_apps), nor does it mention prerequisites or when not to use.

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

list_appsA

List the caller's developer apps (PII-masked).

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the action and the PII-masking behavior, lacking details on read-only nature, authentication requirements, rate limits, or potential 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.

Conciseness5/5

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

The description is a single, concise sentence that front-loads the key information. Every word is necessary and there is no redundancy.

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?

The tool has low complexity with no parameters and no output schema. The description provides the basic function but does not specify the output fields or any sorting/filtering behavior. While adequate for a simple list, it could be more complete to reduce ambiguity.

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?

There are zero parameters, and the schema is empty with full coverage. The description adds value by noting that the output is PII-masked, which is not indicated by the schema, so it provides meaningful context beyond the structured data.

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 'List' and identifies the resource as 'caller's developer apps' with the qualifier 'PII-masked'. It clearly distinguishes this from sibling tools which focus on different operations like deploying or validating IR.

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 on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or any context about appropriate usage scenarios.

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

run_read_toolB

Run a READ-only tool of a deployed app (refuses write/destructive).

Name	Required	Description	Default
`app_id`	Yes
`function`	Yes
`args`	No

TDQS

B3.2/5.0

Behavior3/5

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

The description discloses the behavioral trait of refusing write/destructive actions, but with no annotations, it lacks details on what happens if a write is attempted, rate limits, or authentication requirements.

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

Conciseness2/5

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

The description is very short but fails to provide essential information about parameters and usage, making it under-specified rather than concise. It is front-loaded but incomplete.

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 the tool has three parameters, no annotations, and no output schema, the description is incomplete. It does not explain what 'args' is for, what 'function' values are valid, or how to find them.

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

Parameters1/5

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

Schema description coverage is 0%, and the description adds no meaning to any of the three parameters (app_id, function, args). The description does not explain what these parameters are or how to use them.

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 it runs a READ-only tool of a deployed app, specifying the verb 'run' and resource 'READ-only tool'. It distinguishes from sibling tools that likely involve writing or destructive actions.

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 implies when to use (for read operations) and when not (refuses write/destructive). It does not explicitly name alternatives but the sibling tools suggest other operations (deploy, smoke, validate).

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

smoke_irA

Run one function of an app.ir.json in an ISOLATED store and report {ok,result,trace}.

Name	Required	Description	Default
`app_ir`	Yes
`function`	Yes
`args`	No

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description must cover behavior. It mentions 'ISOLATED store' indicating safety from side effects, and output format {ok,result,trace}. However, it lacks details on auth requirements, rate limits, or what happens to the store after execution.

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?

Single sentence, no fluff. Core information (verb, resource, isolation, output) is front-loaded. Each word serves a purpose.

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 no output schema, the description helpfully includes output format. But with nested objects and no parameter details, the description leaves gaps. The isolated store hint is valuable but overall could be more comprehensive.

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

Parameters2/5

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

Schema coverage is 0%, so description must compensate. It does not explain the app_ir object structure, function name format, or how args should be provided. The description uses general terms 'one function' without clarifying parameter semantics.

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 runs a function from an app.ir.json in an isolated store and reports the result in a structured format. It distinguishes itself from siblings like deploy_ir (deployment) and validate_ir (validation) by focusing on isolated execution.

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

Usage Guidelines3/5

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

The description implies use for testing functions in an isolated environment but does not explicitly state when to use or avoid this tool compared to alternatives like run_read_tool or deploy_ir. No when-not-to-use or prerequisite info.

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

validate_irC

Validate an app.ir.json locally (envelope + every declarative step).

Name	Required	Description	Default
`app_ir`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It only mentions 'validate locally' and 'envelope + every declarative step' but omits details on what validation entails, side effects, or output behavior.

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 a single concise sentence, but it is underspecified and lacks structure. It sacrifices necessary details for brevity.

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 the lack of annotations, output schema, and parameter descriptions, the description is insufficient for an agent to correctly invoke the tool. It fails to provide parameter guidance and behavioral context.

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

Parameters1/5

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

The single parameter 'app_ir' is an object with no description in the schema (0% coverage). The description does not explain what this parameter should contain, leaving the agent with only the type information.

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 verb 'Validate' and the resource 'app.ir.json', with additional scope clarification 'locally (envelope + every declarative step)'. It effectively distinguishes from sibling tools like deploy_ir and smoke_ir.

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

Usage Guidelines3/5

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

The description implies local validation before deployment but does not explicitly state when to use this tool versus alternatives like deploy_ir or smoke_ir. No when-not or alternative guidance is provided.

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.

6 tool updatesv0.1.0Jun 21, 2026
- First observeddeploy_ir
- First observedget_app
- First observedlist_apps
- First observedrun_read_tool
- First observedsmoke_ir
- First observedvalidate_ir

Deploy Server

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

TDQS

A3.5/5.0

Scored 2026-06-21 16:20 across 6 tools

Disambiguation5/5

Each tool targets a distinct action: deploy, get, list, run read-only, smoke test, and validate. No overlapping purposes.

Naming Consistency4/5

Most tools follow verb_noun pattern (deploy_ir, get_app, list_apps, validate_ir), but 'run_read_tool' uses an adjective and 'smoke_ir' uses an unconventional verb, creating minor inconsistency.

Tool Count5/5

With 6 tools, the server covers key operations for managing IR-based apps without being overwhelming. The scope is well-balanced.

Completeness3/5

Core workflows are covered (validation, deployment, listing, reading), but missing update/delete for apps and any write tool execution, leaving notable gaps for full lifecycle management.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Related MCP Connectors

Air Pipe B
io.airpipe
Build, validate, deploy — HTTP APIs, cron jobs, webhooks and MCP tools — from your AI client.
Developer Tools CI/CD & DevOps App Automation
191
https://api.airpipe.io/mcp
JustDeployOAuth
ai.justdeploy
Deploy and manage your apps, databases, storage, and scheduled jobs from your AI agent
Cloud Platforms CI/CD & DevOps App Automation
2
https://mcp.justdeploy.ai/mcp
MeroFoundryOAuth
com.merofoundry
Build and publish full-stack apps from your coding agent: models, rules, pages, auth, per-app MCP.
Coding Agents Developer Tools
1
https://platform.merofoundry.com/mcp
AppDeploy AOAuth
ai.appdeploy
AppDeploy turns app ideas described in AI chat into live full-stack web applications
App Automation CI/CD & DevOps Developer Tools
262
https://api-v2.appdeploy.ai/mcp

Related MCP Servers

WebEvalAgent MCP Serverofficial
Browser Automation Testing & QA Tools
refreshdotdev
A
license
A
quality
F
maintenance
Unleashes LLM-powered agents to autonomously execute and debug web apps directly in your code editor, with features like webapp navigation, network traffic capture, and console error collection.
Updated 9 months ago (2026-02-11 14:55 UTC)
2
1,231
Apache 2.0
Laminar MCP Server
App Automation Developer Tools Workplace & Productivity
laminar-run
F
license
Not graded
quality
Not graded
maintenance
Integrates Laminar workspaces with AI editors to manage workflows, steps, and configuration stores. It allows users to execute, monitor, and debug workflow executions through natural language commands.
Updated 8 months ago (2026-03-12 00:55 UTC)
308 npm
1
-
Context7 MCP Server
Developer Tools Code Analysis AI & Machine Learning
Mapileon2
A
license
Not graded
quality
D
maintenance
Enables LLM-powered code analysis, generation, debugging, and context management through MCP integration with IDEs like Cursor and Claude Desktop.
Updated a year ago (2025-08-20 20:45 UTC)
MIT
Databricks Code Execution MCP
Code Execution Cloud Platforms CI/CD & DevOps
databricks-solutions
F
license
Not graded
quality
C
maintenance
Enables AI-assisted development by running and testing code directly on Databricks clusters via natural language, then deploying Databricks Asset Bundles.
Updated 9 months ago (2026-02-03 15:03 UTC)
14
-

imperal-mcp - The Exoskeleton for Your AI Coding Agent 🐝

The problem

The fix: put your agent in an exoskeleton

Hallucinations: caught before they reach you

Powered by ICNLI - the new HTTP for AI

Quick start

For the geeks: how it works

The loop

Hooks (installed by imperal-mcp setup)

Tool catalog (34 tools, 4 resources, 1 prompt)

CLI

Privacy

Python 3.7 - 3.14

Built like a vault

What leaves your machine

How it's locked down

And on your machine

FAQ

Author

License, protocol & trademarks

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

WebEvalAgent MCP Serverofficial

Hooks (installed by `imperal-mcp setup`)