iron-manus-mcp

by dnnyngyen

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.4
Disambiguation3/5
JARVIS and IronManusStateGraph both deal with state management, creating potential confusion. Other tools like APITaskAgent, PythonComputationalTool, HealthCheck, and SlideGenerator are more distinct, but HealthCheck's abstract description adds ambiguity.
Naming Consistency3/5
Most tools follow PascalCase (APITaskAgent, PythonComputationalTool, etc.), but JARVIS is an all-caps acronym outlier. There is no verb_noun pattern; names are descriptive nouns or proper names.
Tool Count4/5
Six tools is a reasonable count for a multi-purpose server covering orchestration, API research, computation, state management, health check, and slide generation—neither too few nor too many.
Completeness2/5
The tool set mixes concrete (SlideGenerator) and abstract (HealthCheck) tools without clear domain coverage. Gaps exist in typical project management functions like file handling or user interaction, and some tools have vague purposes.
Average 2.8/5 across 6 of 6 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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. It mentions 'automatically validates sources' and 'comprehensive data synthesis' but does not disclose side effects, authentication requirements, rate limits, or whether the tool makes external API calls. The behavior is described in lofty terms without concrete details.
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 verbose and repetitive, using multiple sentences to convey vague concepts. It could be condensed into a clear single sentence about what the tool does. The metaphorical language ('cognitive role', 'strategic API selection') wastes words without adding clarity.
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?
With 8 parameters, 2 enums, and no output schema, the description should explain what the tool returns or how it behaves. It mentions 'data synthesis with actionable insights' but lacks specifics. The agent needs more context on the tool's output format and capabilities to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds little extra meaning beyond rephrasing parameter descriptions (e.g., 'Cognitive perspective' for user_role). It does not harm, but also does not significantly enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses abstract language like 'orchestrates discovery, validation, and data fetching workflows' without specifying a concrete action or resource. It does not clearly state what the tool does with a specific verb and object. The purpose is vague and hard to distinguish 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some context ('when you need structured data from external sources') but lacks explicit when-to-use or when-not-to-use guidance. It does not differentiate from sibling tools like JARVIS or PythonComputationalTool, leaving the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It fails to describe what the tool actually does—e.g., what endpoints it hits, what checks it performs, or its safety profile. Metaphorical language ('thinking clearly') does not convey concrete behavior.
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 overly verbose and uses rhetorical questions ('What might cognitive degradation look like?') that waste space. A concise description would state the tool's function directly.
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?
No output schema exists, so description should explain return value or side effects. It does not. The tool has only one optional parameter, but the description leaves the agent without sufficient information to predict the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'detailed' parameter has a description that adds some meaning ('Diagnostic depth preference'), but it remains abstract. Schema coverage is 100%, so baseline is 3; the description provides marginal extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses vague terms like 'cognitive readiness' and mixes operational health with intelligence assessment, failing to state a clear verb+resource. It does not distinguish from sibling tools like JARVIS or PythonComputationalTool.
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 guidelines on when to use this tool versus alternatives. The description lacks any context on prerequisites or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It mentions 'FSM state management' and 'isolated state per project' but fails to list supported actions, side effects, or permissions needed. The 15-parameter schema implies complexity not addressed.
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 concise at two sentences, with no wasted words. However, it lacks structure (e.g., bullet points or sections) that could improve readability for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 parameters, 12 actions, no output schema), the description is severely incomplete. It does not explain return values, how actions relate, or typical usage flows, leaving the agent without sufficient context to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides, thus neither improving nor degrading clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool manages project-scoped FSM state using knowledge graphs, specifying it handles sessions, phases, tasks, and transitions. It distinguishes from sibling tools by its domain focus, though it could be more precise about the actions supported.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or scenarios where other tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions 'automatic library management' implying package installation, but does not disclose side effects like system modifications, security risks of executing custom code, or output behavior. Critical behavioral traits are missing for a code execution tool.
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?
Single sentence is concise but packed with buzzwords ('unified', 'automatic library management', 'comprehensive workflow support') without elaboration. Lacks front-loaded action verb and could benefit from clearer structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 4 parameters (including nested object) and no output schema or annotations, the description is incomplete. Does not explain return values, error handling, or operational constraints. Significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions exist for all parameters (100% coverage), but they are minimal: e.g., 'parameters' is described as 'Operation-specific parameters and configuration' without specifying structure. The description adds no extra meaning beyond schema; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states it's a 'Unified Python execution and data science tool' with automatic library management and workflow support. The operation enum clarifies specific tasks like web scraping and machine learning. However, it does not distinguish from sibling tools which appear unrelated but are still alternatives in the toolset.
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 on when to use this tool vs siblings (JARVIS, APITaskAgent, etc.). No indication of prerequisites, when to choose a specific operation, or when not to use the tool. The description is too vague to help an agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action and output. It does not disclose side effects, idempotency, authentication needs, or whether sessionId implies workspace file modifications. Minimal behavioral insight beyond the basic operation.
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, well-structured sentence that front-loads the core action and result. Every word is informative, with zero redundancy or filler.
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?
Despite having 4 parameters including nested objects, the description is too brief. It lacks context about the overall process (e.g., whether multiple slides can be generated, how sessionId affects file management, or what designOptions does). The absence of an output schema makes the description insufficient for complex usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is documented in the schema. The description adds no additional semantic information beyond summarizing the required params (templateId, contentData). Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Generates' and the resource 'HTML slides from templates and content data', with a specific result 'returns rendered slide HTML'. It unambiguously defines the tool's function and distinguishes it from the unrelated 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, prerequisites, or exclusions. Sibling tools are unrelated, but there is no explicit context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions key behaviors like single-tool-per-iteration enforcement and fractal decomposition, but omits details on error handling, state persistence, or what happens when invalid phase_completed values are provided. The behavioral coverage is adequate but incomplete.
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 informative and structured with a clear opening sentence followed by a bullet-like list of features. However, it contains some redundant phrasing (e.g., 'Enables Claude to autonomously manage complex projects through context segmentation') that could be trimmed without loss of clarity.
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 and moderate complexity, the description covers the phase loop and key features but lacks details on expected return values, state transition rules, and post-execution behavior. It is adequate for basic usage but leaves gaps for an agent needing precise context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add significant meaning beyond the schema's parameter descriptions; it merely reiterates the phase completion semantics and session handling. No additional value for parameter understanding.
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 identifies the tool as a 'Finite State Machine Controller' implementing an 8-phase agent loop, with a specific verb ('implements') and resource ('8-phase agent loop'). It distinguishes itself from siblings by detailing unique features like fractal task decomposition and single-tool-per-iteration enforcement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus its siblings (e.g., APITaskAgent, IronManusStateGraph). It lacks explicit 'when to use' or 'when not to use' criteria, leaving the agent to infer applicability from the feature list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![iron-manus-mcp MCP server](https://glama.ai/mcp/servers/dnnyngyen/iron-manus-mcp/badges/card.svg)](https://glama.ai/mcp/servers/dnnyngyen/iron-manus-mcp)

Score Badge

Copy to your README.md:

[![iron-manus-mcp MCP server](https://glama.ai/mcp/servers/dnnyngyen/iron-manus-mcp/badges/score.svg)](https://glama.ai/mcp/servers/dnnyngyen/iron-manus-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/dnnyngyen/iron-manus-mcp'

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