Make MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation1/5
The tool names are entirely opaque, consisting only of scenario IDs like 'run_scenario_11422' with no indication of their distinct purposes. From the descriptions, some tools appear to handle inventory operations while others deal with scenario inputs or testing, but the naming provides no disambiguation, making it impossible for an agent to reliably choose between them without guessing.
Naming Consistency5/5
All tool names follow a perfectly consistent pattern: 'run_scenario_' followed by a numeric ID. While this pattern is uninformative, it is uniformly applied across all six tools, with no deviations in style or structure.
Tool Count3/5
With 6 tools, the count is reasonable and not excessive. However, given the unclear domain inferred from the tool names and descriptions—which suggest a mix of inventory management, scenario testing, and input handling—it's borderline whether this number adequately covers the scope, as the tools seem fragmented rather than cohesive.
Completeness2/5
Inferred domain includes inventory management and scenario testing, but there are significant gaps. For inventory, only list and add operations are present, missing update and delete. For scenario inputs and testing, the tools are vague and incomplete, lacking clear CRUD or lifecycle coverage, which will likely cause agent failures in complex tasks.
Average 1.8/5 across 6 of 6 tools scored. Lowest: 1.1/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 12 community issues answered or closed in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
This repository includes a glama.json configuration file.
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

Behavior1/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 behavioral disclosure but fails completely. 'Scenario Inputs All Types' doesn't indicate whether this is a read or write operation, what kind of scenario is being run, what effects it has, or any behavioral characteristics like rate limits, authentication needs, or error conditions. This leaves the agent with no understanding of the tool's 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?
While technically concise (three words), this is a case of harmful under-specification rather than effective brevity. The description fails to convey necessary information and wastes its minimal word count on a tautological phrase. Every sentence should earn its place, but this description doesn't provide a single useful sentence.
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 (10 parameters including nested objects, arrays of arrays, and collections), lack of annotations, absence of output schema, and presence of five sibling tools, the description is completely inadequate. It provides no context about what the tool does, when to use it, what behavior to expect, or how parameters relate to the scenario execution. This leaves the agent unable to properly understand or invoke the tool.
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 schema has 10 parameters with 70% description coverage, but the description 'Scenario Inputs All Types' adds zero semantic information about any parameters. It doesn't explain what these inputs represent, how they relate to the scenario, or provide any context beyond what's minimally documented in the schema. For a complex tool with 10 parameters including nested objects, this is completely inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Scenario Inputs All Types' is a tautology that restates the tool name 'run_scenario_11704' without specifying what the tool actually does. It doesn't identify a specific action (verb) or resource, nor does it distinguish this tool from its five sibling tools (run_scenario_11422, etc.). This provides no meaningful information about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus its five sibling tools or any alternatives. There's no mention of context, prerequisites, or distinctions between this and other scenario-running tools. The agent would have no basis for selecting this specific tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 of behavioral disclosure. It fails to describe any behavioral traits—such as whether it's read-only or destructive, what permissions are needed, or what the tool outputs—making it impossible for an agent to understand how the tool behaves.
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?
While concise with a single phrase, it's under-specified rather than efficiently structured. The description lacks essential information, making it ineffective—conciseness should not come at the cost of clarity, and this text fails to earn its place by adding value.
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 complexity implied by 'run_scenario' and the lack of annotations, output schema, or schema descriptions, the description is completely inadequate. It doesn't explain the tool's purpose, behavior, parameters, or results, leaving critical gaps for agent invocation.
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 schema description coverage is 0%, and the description only vaguely references 'Array of Collections' without explaining what 'Collections' are, what the 'text' property means, or how the array should be structured. It adds no meaningful semantics beyond the bare schema.
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 'Scenario Inputs: Array of Collections' is vague and tautological—it restates the parameter name ('array') without specifying what the tool actually does. It mentions 'Scenario' but doesn't define what a scenario is or what action 'run' entails, failing to distinguish it from sibling tools like run_scenario_11422.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 offers no context, prerequisites, or exclusions, leaving the agent with no basis to choose between this and sibling tools like run_scenario_11652 or run_scenario_11704.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 of behavioral disclosure. However, it offers no information about what the tool does (e.g., whether it runs a simulation, processes data, or performs another action), its effects, permissions needed, or any constraints like rate limits.
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?
While concise with only three words, the description is under-specified rather than efficiently informative. It fails to convey essential details, making brevity a detriment rather than a strength in this context.
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 lack of annotations, no output schema, and a parameter with 0% schema coverage, the description is completely inadequate. It does not compensate for these gaps, failing to provide any meaningful context about the tool's purpose, usage, or behavior.
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 input schema has one parameter ('text') with 0% description coverage, and the tool description adds no meaning about this parameter. It does not explain what 'text' represents, its format, or how it influences the tool's behavior, leaving the parameter entirely undocumented.
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 'Scenario D - Subscenario' is vague and tautological—it restates the tool name 'run_scenario_8632' without specifying what the tool actually does. It lacks a clear verb and resource, failing to distinguish this tool from its siblings (e.g., run_scenario_11422, run_scenario_11652).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 its sibling tools. The description does not mention any context, prerequisites, or alternatives, leaving the agent with no information to make an informed selection among similar-named tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 behavioral disclosure but fails completely. 'Dynamic Connections Testing' gives no indication of whether this is a read or write operation, what side effects it might have, what permissions are required, or what the expected behavior is. The agent has no way to understand what actually happens when this tool is invoked.
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 extremely concise (two words) but this brevity comes at the cost of meaningful information. While it's technically 'front-loaded' (there's only one phrase), it's so underspecified that it fails to communicate essential information about the tool's purpose and usage.
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 a tool with 1 undocumented parameter, no annotations, no output schema, and five similar sibling tools, the description is completely inadequate. It provides no meaningful context about what the tool does, how to use it, what parameters mean, or how it differs from alternatives. This leaves the agent unable to make informed decisions about tool selection and invocation.
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 input schema has 1 parameter (AirtableConnection) with 0% description coverage, meaning the schema provides no documentation about this parameter. The description 'Dynamic Connections Testing' adds absolutely no information about what the AirtableConnection parameter represents, what format it expects, or how it relates to the testing operation.
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 'Dynamic Connections Testing' is vague and tautological - it essentially restates the tool name 'run_scenario_2361' in different words without specifying what action is performed or what resource is affected. It doesn't distinguish this tool from its five sibling 'run_scenario_*' tools, all of which presumably also involve some form of scenario testing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus the five sibling tools (run_scenario_11422, run_scenario_11652, etc.). There's no indication of what makes scenario 2361 different from other scenarios, nor any context about appropriate use cases or prerequisites.
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 for behavioral disclosure. While 'Add to Inventory' implies a write/mutation operation, the description doesn't specify permissions needed, whether the operation is idempotent, what happens on duplicate items, or what the response contains. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.
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 extremely concise - just one sentence that states the tool's core function. While this is efficient, it borders on under-specification given the lack of context about what 'inventory' means in this scenario system. Every word earns its place, but more context would be helpful.
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 mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what constitutes a valid 'item', how the inventory is structured, what happens after addition, or any error conditions. The agent lacks crucial context to use this tool effectively in the scenario-based system with multiple sibling tools.
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% with the single 'name' parameter well-documented in the schema. The description doesn't add any parameter semantics beyond what the schema already provides (e.g., no format requirements, length limits, or examples). With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'Add a new item to the inventory', which is a clear verb+resource combination. However, it doesn't distinguish this tool from its siblings (run_scenario_11422, etc.), which all appear to be scenario-based tools with generic names. The description is vague about what 'inventory' refers to in this specific scenario context.
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 its sibling tools. There's no mention of alternative tools, prerequisites, or specific contexts where this inventory addition is appropriate. The agent must infer usage from the generic description alone.
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 are provided, so the description carries the full burden of behavioral disclosure. The description only states what the tool does ('Lists items in inventory') without mentioning any behavioral traits like whether this is a read-only operation, if it requires authentication, what format the output takes, or any rate limits. For a tool with zero annotation coverage, this is insufficient.
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 extremely concise ('Tool: List Inventory (Lists items in inventory.)') with no wasted words. It's front-loaded with the tool name and purpose. However, the structure is slightly awkward with the parenthetical repetition, and it could be more polished while maintaining 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 and output schema, the description is incomplete. It doesn't explain what 'inventory' refers to, what format the list takes, or how this tool differs from its siblings. For a tool with no structured metadata, the description should provide more context to be fully usable by an agent.
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?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of parameters. The description doesn't need to add parameter semantics, and it correctly doesn't mention any parameters. A baseline of 4 is appropriate for zero-parameter tools when the schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'Lists items in inventory', which is a clear verb+resource combination. However, it doesn't distinguish this tool from its siblings (all named 'run_scenario_XXXX'), leaving the agent uncertain about what makes this specific scenario unique. The description is adequate but lacks sibling differentiation.
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 about when to use this tool versus the five sibling 'run_scenario' tools. The description doesn't mention any context, prerequisites, or alternatives, leaving the agent with no usage guidelines beyond the basic purpose statement.
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:

[![make-mcp-server MCP server](https://glama.ai/mcp/servers/integromat/make-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/integromat/make-mcp-server)

Score Badge

Copy to your README.md:

[![make-mcp-server MCP server](https://glama.ai/mcp/servers/integromat/make-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/integromat/make-mcp-server)

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/integromat/make-mcp-server'

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