Make MCP Server

Server Quality Checklist

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

Latest release: v1.6.0
Disambiguation5/5
Every tool targets a distinct resource and action: scenarios, executions, data stores, webhooks, connections, and org/team listing are clearly separated. Even related tools like make_run_scenario vs make_trigger_webhook are distinguishable by their mechanism and descriptions.
Naming Consistency5/5
All tools follow a consistent make_verb_noun snake_case pattern. Singular 'get' for single items and plural 'list' for collections is applied uniformly. The only slight outlier is make_open_in_browser, but it still fits the make_ prefix convention.
Tool Count4/5
At 26 tools, it's slightly above the 'heavy' range, but the count is justified by the broad scope of Make.com management: scenarios, executions, DLQ, data stores, webhooks, and connections each require several dedicated operations. No tool feels redundant.
Completeness3/5
Scenario execution and DLQ handling are well covered, and data store record CRUD exists. However, there are notable gaps: no scenario create/delete, no data store create/update/delete, and no webhook create/delete. These are obvious lifecycle operations for the domain and would require workarounds.
Average 4.1/5 across 26 of 26 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 commits in the last 12 weeks
- Last stable release on July 30, 2026
- 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.
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 provided, and description only states the action without disclosing behavioral traits like safety, user consent, or potential side effects (e.g., triggering browser navigation).
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, efficient, front-loaded with key information, no unnecessary words.
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?
For a simple tool with one parameter and no output schema, the description is nearly complete; minor gap is lack of safety or permission 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 coverage is 100% for the single 'url' parameter; description adds an example (scenario editor link) but no additional semantic meaning beyond the schema.
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?
Description clearly states action ('Open a Make.com URL') and target ('in the default browser'), distinguishing it from sibling tools that retrieve or manage scenario data.
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?
No explicit guidance on when to use or avoid, but the purpose is clear and siblings cover different functions, so usage is implied.
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, the description carries full burden. It discloses that the scenario will run on its schedule or trigger, implying it is not an immediate forced run. However, it does not mention potential side effects (e.g., what happens if already active), prerequisites (permissions), or error conditions.
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 single sentence is front-loaded with the action and is efficient. No redundant words. Could be slightly improved by adding a usage note, but remains concise.
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 one parameter and no output schema, the description adequately conveys that activation enables scheduled/triggered runs. However, it omits preconditions (e.g., scenario must exist, user must have permissions) and what happens if already active. Adequate but not exhaustive.
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 coverage is 100% for the single parameter 'scenario_id', and the description adds no additional meaning beyond the schema's own description. Baseline 3 is appropriate as the description does not detract but also does not enhance 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 uses a specific verb 'Activate' and clearly identifies the resource 'Make.com scenario'. It distinguishes from siblings like make_run_scenario (immediate run) and make_stop_scenario (deactivate) by mentioning 'turn ON / schedule' and 'runs on its schedule or trigger'.
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 scheduling or triggering a scenario, but does not explicitly state when to use this tool versus alternatives like make_run_scenario for immediate execution or make_stop_scenario for deactivation. No when-not-to-use guidance is provided.
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?
No annotations provided, so description must stand alone. It states 'Get full details... (status, scheduling, team, description, etc.)' but does not disclose potential errors, rate limits, or whether the operation is read-only (implied but not explicit). Adequate for a simple retrieval.
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, front-loaded with purpose and scope. No unnecessary words. Appropriate length.
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?
Simple retrieval tool with one parameter, no output schema, no nested objects. Description covers the basic purpose and parameter, but could benefit from mentioning the output structure or example. Adequate but minimal.
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 coverage is 100% with one parameter 'scenario_id' described as 'The scenario ID'. Description adds 'by its ID' but no additional meaning beyond the schema. Baseline 3.
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?
Clearly states 'Get full details of a single Make.com scenario by its ID', specifying the action (get), resource (scenario), and scope (single, full details, by ID). Distinguishes from sibling tools like 'make_list_scenarios' which lists multiple scenarios.
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?
Implied usage: when you need full details of a single scenario by ID. No explicit when-to-use or when-not-to-use compared to siblings like 'make_list_scenarios' or 'make_get_execution'. Minimal guidance.
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 full responsibility. It does not disclose whether the operation is read-only, destructive, or has any side effects, rate limits, or authentication requirements. While listing is typically safe, the description should explicitly state its read-only nature.
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?
Two sentences, no wasted words. Essential information (action, output, parameter behavior, sibling reference) is front-loaded and efficiently communicated.
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?
For a list tool with no output schema, the description adequately covers the return fields and references a sibling tool. The parameter explanation is sufficient. It could mention if pagination exists or if it's limited, but overall it is complete for its complexity.
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 input schema has one parameter with 100% description coverage. The description adds context about the fallback behavior, which is consistent with the schema. However, it does not provide additional details beyond what the schema already conveys. Baseline 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 action 'list', the resource 'webhooks for a team', and specifies the returned fields (id, name, webhook URL). It also differentiates this tool from the sibling 'make_trigger_webhook' by noting the URL is used by that tool. No ambiguity.
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 explains that the output includes the webhook URL used by make_trigger_webhook, implying a use case. It also clarifies the fallback behavior for team_id. However, it does not explicitly state when not to use this tool or mention alternative tools for similar purposes.
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?
No annotations provided, so description bears full burden. It states the action but omits details like impact on running executions, reversibility, or required permissions. Adequate for a simple tool.
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, front-loaded key information. No unnecessary words.
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?
With one parameter and no output schema, the description sufficiently covers the tool's purpose. Could add more behavioral context but not essential.
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 coverage is 100% for the single parameter. Description adds 'The scenario ID to deactivate', which aligns with schema but adds minimal extra meaning.
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 specific verbs ('Deactivate (turn OFF)') and clearly identifies the resource ('Make.com scenario'). It effectively distinguishes from sibling tools like make_start_scenario.
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 when stopping a scenario but lacks explicit guidance on when to use versus alternatives (e.g., make_run_scenario for one-off runs) or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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. It states that the tool 're-checks the saved credentials against the app' and returns a 'verified' status, which implies a read-only test. This is sufficient for a non-destructive, verification operation, though it could mention error conditions or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that immediately state the tool's purpose and outcome. Every word adds value, with no filler or repetition. The front-loaded structure helps the agent quickly grasp the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (one parameter, no output schema), the description covers the essential aspects: what it does, what it returns ('verified' status). However, it could be more specific about the return format (e.g., boolean or string) and potential error messages. Overall, it is nearly complete.
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 input schema has 100% description coverage for the single parameter connection_id, which already explains it is obtained from make_list_connections. The tool description adds no additional meaning beyond the schema, so 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Verify whether a Make.com connection is still valid.' This is a specific verb (verify) and resource (connection). It distinguishes itself from sibling tools like make_list_connections, which list connections but do not test validity. The additional detail about re-checking credentials reinforces its unique function.
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 explicit guidance on when to use this tool versus alternatives. It lacks mention of prerequisites, such as having a valid connection_id, or when not to use it (e.g., if the connection was just created). The agent is left to infer usage from the verb 'verify' without clear context.
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?
The description discloses that 'data' replaces the entire record, which is a key behavioral trait. However, with no annotations provided, it lacks details on error cases, authentication, or idempotency.
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?
Two concise sentences that front-load the main action and parameter role. No extraneous information.
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?
Covers the core action and parameter meaning. Lacks information on error handling or prerequisites, but for a simple update operation, it is nearly complete.
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 coverage is 100%, with descriptions for all parameters. The description reinforces the schema's meaning for 'data' but adds no new semantic details beyond the schema.
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 'Replace an existing record', specifying the verb and resource. It distinguishes from siblings like 'make_add_record' and 'make_delete_record' by indicating it's a replacement operation.
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 does not explicitly state when to use this tool versus alternatives. While the purpose is clear, there is no guidance on prerequisites or when not to use it.
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?
No annotations provided, so description must cover behavioral aspects. It notes key auto-generation but omits error handling, idempotency, permission requirements, or 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?
Two concise sentences, front-loaded with purpose. Every sentence adds value.
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?
Covers key usage aspects for a simple create tool. Missing details on duplicate keys or return values, but adequate for typical use.
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 coverage is 100%. Description adds context that data must match data store's structure, but key and data_store_id add little beyond the schema.
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?
Describes adding a new record to a Make.com data store with clear verb and resource. Distinguishes from sibling tools like make_delete_record or make_update_record.
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?
Explains the data parameter structure and optional key with auto-generation. Implicitly guides when to use (adding records), but lacks explicit when-not or alternatives.
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, the description carries the full burden. It explains that the tool retrieves historical input/output values behind a failed execution, which is useful behavioral context. However, it does not mention whether the operation is read-only, possible response size, or any permissions needed. This is a minor gap for a 'get' tool.
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?
Two tightly written sentences that front-load the main purpose, provide a concrete use case, and cross-reference the sibling tool. Every phrase earns its place with zero fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (one parameter, no output schema) and sufficient annotations absence, the description covers what the tool does, why to use it, and how to get the ID. It doesn't describe the return structure in detail, but for this level of complexity the guidance is largely complete.
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 coverage is 100%: the single parameter dlq_id is already described as 'The incomplete-execution (DLQ) id from make_list_incomplete'. The description reiterates this context, but adds no new syntax or format details. Baseline 3 is appropriate given the schema fully documents the parameter.
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?
Clearly states the verb 'Get' and the specific resource: the data bundle being processed at the moment of a scenario execution failure. It distinguishes itself from sibling tools by referencing make_list_incomplete and emphasizing the actual input/output values, not just execution status or error messages.
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?
Provides explicit context for when to use the tool ('real diagnosis instead of guessing from error messages alone') and implies the prerequisite of calling make_list_incomplete to obtain the dlq_id. While no formal alternative or exclusion is given, the guidance is clear and practically useful.
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?
No annotations provided, so the description carries full burden. It mentions the tool returns status, operations, duration, and error info, but does not explicitly state it is read-only or disclose any authorization needs or rate limits. For a simple retrieval tool, this is adequate but lacks some behavioral context.
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 purpose and includes necessary context. Every word contributes to understanding, with no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 simple params, no output schema), the description is fairly complete. It explains what the tool does and how to obtain the required parameters. It mentions the type of details returned, which is helpful, though a bit more detail on the return structure would be useful.
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 coverage is 100%, with each parameter having a description. The description adds context that execution_id comes from make_list_executions, but beyond that, it does not add significant meaning beyond the schema.
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', the resource 'full details of a single scenario execution/log', and the key identifiers (scenario_id + execution_id). It distinguishes itself from sibling tools like make_list_executions (which lists) and make_get_scenario (which gets scenario details).
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 explicitly tells users to obtain execution_id from make_list_executions, providing a clear prerequisite. It implies it is for detailed view after listing, though it does not explicitly state when not to use it or name alternatives.
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?
No annotations provided, so description must shoulder the burden. It discloses the default limit and cap, but does not mention read-only nature, authentication requirements, or any potential side effects. Acceptable but minimal.
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?
Two sentences delivering all essential information. No redundancy. Front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description compensates by describing record structure. Covers purpose, limit behavior, and result shape. Lacks error conditions or pagination details, but adequate for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description adds value beyond schema by explaining the result structure (key and data object) and that limit defaults to 100. This aids 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 states the verb 'List' and the resource 'records in a Make.com data store'. It distinguishes from siblings like make_add_record and make_delete_record, providing a specific scope.
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 mentions default cap and max, but lacks explicit guidance on when to use this tool versus alternatives like make_list_data_stores or other sibling tools. No when-to-use or when-not-to-use context.
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?
No annotations provided. Description discloses ordering ('newest first') and output content (success/failure, time). Lacks details on pagination, rate limits, or authentication, but is sufficient for a read-only list 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?
Two terse sentences with no fluff. Information is front-loaded and each sentence adds value.
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?
No output schema, but description mentions output fields (success/failure, time). Could include more details like pagination or error message format, but adequate for typical use.
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 coverage is 100%. Description adds context like status values and ordering beyond schema, but does not significantly enhance parameter understanding beyond schema 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?
Description clearly states 'List the execution history (logs) of a Make.com scenario' with specific verb and resource, and distinguishes from sibling tool make_get_execution which likely gets a single execution.
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?
Description implies usage for viewing execution history with optional filtering by status. Does not explicitly exclude when not to use, but is generally clear.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool lists failed executions that are waiting, indicating a non-destructive read operation. However, it does not mention behavior such as pagination, rate limits, or what happens if no failed executions exist. The description is adequate but not detailed.
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?
Two sentences, zero wasted words: first sentence states purpose clearly, second gives usage guidance. Perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 parameters, no output schema, no annotations), the description is fairly complete. It explains what the tool does, what it lists, and when to use it. It lacks explicit differentiation from make_list_executions but is sufficient for basic use.
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 coverage is 100%, so both parameters are already documented. The description adds overall context (DLQ, retry usage) but does not add specific parameter-level details beyond what the schema provides. Baseline 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 ('List') and resource ('incomplete/failed executions (DLQ) of a Make.com scenario'), and explains what these executions are ('runs that errored and are waiting'). This distinguishes it from siblings like make_list_executions (which lists all executions) and make_retry_execution (which retries).
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 explicitly states when to use this tool: 'Use this before retrying.' This provides clear context. However, it does not specify when not to use it or mention alternative tools explicitly, though the sibling context implies differentiation.
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?
No annotations, so description carries burden. Mentions it returns id+name, implying read-only. Does not disclose pagination, rate limits, or edge cases (e.g., large orgs). Adequate but not detailed.
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?
Two sentences, no wasted words. First sentence states core purpose, second adds parameter context. Perfectly concise.
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?
Almost complete for a simple list tool with 1 optional parameter and no output schema. Includes parameter behavior and sibling dependency. Missing explicit 'returns a list' wording, but implied. Left minor gaps.
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 coverage is 100%, so baseline is 3. Description adds minimal value by rephrasing fallback behavior: 'configured one is used, or the single org is auto-selected'. Slightly helpful but not necessary given schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List'), resource ('teams inside a Make.com organization'), and output ('id + name'). It also connects to sibling tool make_list_scenarios, reinforcing purpose.
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?
Provides clear context: teamId from this tool is needed by make_list_scenarios. Explains organization_id fallback behavior. No explicit when-not-to-use, but sufficient for a simple list tool.
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 mentions that the webhook 'FIRES the scenario for real', indicating actual execution. It does not disclose potential side effects, rate limits, or error conditions, but the core behavior is adequately described.
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?
Two sentences with no waste. The key information is front-loaded: action, method, source, and parameter hint. Every sentence adds value.
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?
For a simple tool with two parameters and no output schema, the description covers purpose, parameter semantics, and behavioral hint. It does not address success/failure responses, but this is acceptable given the tool's simplicity.
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 coverage is 100%, so baseline is 3. The description adds minimal value beyond the schema: it notes the URL source and optional nature of data. No further semantic detail is provided.
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 triggers a Make.com scenario via webhook POST, and references make_list_hooks for obtaining the URL. It distinguishes itself from sibling tools by focusing on webhook triggering, which is unique among listed siblings.
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 usage by specifying the action and source of the webhook URL. However, it lacks explicit when-to-use or when-not-to-use guidance compared to alternatives, such as prerequisites like scenario activation.
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?
No annotations are provided, so the description carries the full burden. It notes the re-run action (mutating), but lacks details on side effects, permissions, or whether the DLQ item is consumed. Adequate but not rich.
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?
Two sentences without wasted words. Front-loaded with action and source of ID, followed by a clarifying statement. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description fully covers what the tool does, its input, and its relation to make_list_incomplete. No gaps given the complexity.
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?
Only one parameter, dlq_id, with 100% schema coverage. The description mentions the ID source from make_list_incomplete, adding no extra meaning beyond the schema. Baseline 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 'retry' and the resource 'incomplete/failed execution (DLQ item)', specifying the ID source from make_list_incomplete. It distinguishes this tool from siblings like make_get_execution or make_run_scenario.
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 usage when you have a DLQ item from make_list_incomplete that needs retrying. It does not explicitly exclude other scenarios or mention alternatives, but the context is clear given sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds value by clarifying the exact scope of deletion and the safety limitation. However, it lacks details on error behavior or idempotency.
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?
Two well-structured sentences with front-loaded verb and resource, zero wasted words. Concisely conveys core purpose and constraint.
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?
Covers key behavioral constraints but does not describe return value or error handling, which would be desirable given no output schema.
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 coverage is 100% and the description effectively paraphrases the schema's parameter descriptions without adding new semantic details beyond the key constraint.
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?
Explicitly states 'Delete SPECIFIC record(s) from a Make.com data store by key(s)', using a specific verb and resource. The clarification that deleting all records is not supported distinguishes it from potential bulk operations.
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?
Clearly indicates usage for deleting specific records only and explicitly says deleting all records is not supported, providing a clear usage boundary. However, it does not name alternative tools for bulk deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It transparently describes the output as the same data Make's editor canvas displays, and details what is included (modules, parameters, filters, connections). It doesn't address side effects or permissions, but for a read-only get operation this is adequate.
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?
Two tight sentences: the first states the core function and content, the second adds context about the data source and a practical use case. Every word earns its place, with no filler or repetition.
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?
For a simple single-parameter tool with no output schema, the description fully covers what to expect (full JSON blueprint) and why to use it. The only minor gaps are authentication or error behavior, but these are not necessary for this straightforward read operation.
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 schema already fully describes the single parameter scenario_id ('The scenario ID'), giving 100% schema coverage. The description adds no additional meaning about the parameter itself, which matches the baseline of 3 for complete schema coverage.
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 'Get the full blueprint (JSON structure) of a Make.com scenario', a specific verb+resource pairing. It enumerates the exact contents ('every module, its parameters, filters and how modules connect'), which clearly distinguishes it from sibling tools like make_get_scenario that likely return only metadata.
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?
It explicitly states when to use the tool: 'Use it to inspect exact module configuration without asking the user for screenshots.' This provides clear context, though it doesn't name alternative tools or explicitly state when not to use it.
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?
No annotations are provided, so the description carries full responsibility. It discloses that the tool reads connections and returns id, name, and app, with team_id fallback. However, it does not mention potential limitations like pagination, rate limits, or whether the operation requires any authentication beyond defaults.
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 two sentences with no wasted words. It efficiently conveys the action, result, and important fallback logic, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no output schema, one optional parameter), the description is largely complete. It explains what is returned and the fallback behavior. Minor omissions include any mention of pagination or ordering, but these are less critical for this type of tool.
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 input schema has 100% coverage for the single parameter team_id. The description adds value by explaining the fallback behavior (configured team or only team), which is not present in the schema. This goes beyond the bare parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Make.com connections (linked app accounts) for a team, providing id, name, and app. It differentiates from sibling list tools by specifying the resource type and return fields.
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 indicates the tool is useful for seeing which integrations are connected, giving a clear use case. It also explains the fallback behavior for team_id. However, it does not explicitly compare to alternatives or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses the team_id fallback and return fields, but does not state read-only nature or any limits beyond the limit parameter.
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?
Two sentences, front-loaded with purpose, every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description specifies return fields (id, name, record info) and explains team_id behavior. Completeness is high for a list tool with simple parameters.
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 provides full descriptions for both parameters (limit, team_id). Description restates the fallback behavior already in schema, adding no new meaning. Baseline 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?
Clearly states the tool lists Make data stores, a specific resource, and distinguishes it from sibling tools like make_list_scenarios by naming the resource type and including record info in returns.
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?
Describes the tool's use case (listing data stores for a team) and the team_id fallback behavior, but doesn't explicitly specify when not to use it or compare with alternatives.
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?
The description indicates that the tool lists organizations accessible by the token, implying a read operation. However, no explicit disclosure of behavior beyond the list itself, such as whether it requires special permissions or has rate limits. No annotations are provided, so the description carries this burden but is somewhat lacking.
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 two sentences with no unnecessary words. It front-loads the action and key output, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description covers the purpose, output, and usage context. It is sufficient for an agent to decide when to invoke it.
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 coverage is 100%. The description adds no parameter information because none is needed. The baseline of 4 applies as the description adequately handles the absence of parameters.
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 'List all Make.com organizations', specifying the verb (list) and the resource (organizations). It also mentions what it returns ('id + name'), which distinguishes it from sibling tools that deal with scenarios, executions, etc.
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 includes explicit guidance: 'Use this first if you don't know the organization_id.' This tells the agent when to use this tool, setting a clear prerequisite. However, no explicit 'when not to use' is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It reveals a safety-driven design choice ('intentionally NOT supported'), clarifies that only the specified ids are removed, and references the source list. It stops short of mentioning permanence or error behavior, but the core behavioral traits are transparent.
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 three sentences with no fluff: state the purpose, give the usage instruction, and note the safety limitation. It is front-loaded with the action verb and every sentence earns its place.
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?
For a simple 2-parameter delete tool with no output schema, the description covers the essential context: what it does, how to use it, and a key boundary (not deleting all). It does not elaborate on edge cases like invalid ids or missing scenarios, but these are not critical for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers 100% of parameters, giving a baseline of 3. The description adds meaningful nuance by specifying dlq_ids must be 'exact ids to delete (from make_list_incomplete)' and reinforcing that only those are removed, which directly clarifies parameter semantics beyond the schema.
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+resource: 'Delete specific incomplete/failed execution(s) (DLQ items) by id, from a given scenario.' It clearly differentiates from siblings by emphasizing 'specific' and 'ONLY those are removed,' distinguishing it from broader operations like retry or list.
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 gives concrete usage direction: pass 'dlq_ids' as an array of exact ids from make_list_incomplete, and explicitly states a when-not: 'Deleting ALL incomplete executions of a scenario is intentionally NOT supported here, for safety.' It does not name an alternative tool, but the guidance is strong and context-rich.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses fallback logic, result capping (default 500), and the 'capped' indicator. It doesn't cover rate limits or authentication, but adds sufficient behavioral context beyond the schema.
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?
Two concise sentences front-load the purpose and key parameters. Every word adds value, no redundancy.
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?
For a list tool with no output schema, the description covers all parameters, fallback, filters, and result limits. It mentions the 'capped' field to indicate truncation, which is complete enough. Missing sorting or pagination details, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). The description adds meaning by explaining the fallback relationship between team_id and organization_id, the effect of active_only, and the limit cap behavior, which goes beyond the schema 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 clearly states the tool lists Make.com scenarios for a team or organization, with specific verb 'List' and resource 'scenarios (automations).' It distinguishes from siblings like make_get_scenario (single scenario) and make_list_executions (different entity).
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 explains when to provide team_id vs organization_id, fallback behavior, and filter options like active_only and limit. It gives clear context for usage, though it doesn't explicitly exclude alternatives or state 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses wait behavior, timeout (~40s), fire-and-forget mode, and error condition. No annotations provided, so description covers key behaviors well, though lacks details like rate limits or idempotency.
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?
Description is about 5 sentences, front-loaded with main action. Each sentence adds value, though could be slightly more concise.
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?
Covers essential usage and return behavior, but lacks description of output format (no output schema) and what happens with invalid scenario_id. Adequate for a moderate complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds meaning beyond schema by explaining the wait parameter's effect on return value and the data parameter's conditional relevance.
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 Make.com scenario on demand. It distinguishes from siblings like make_start_scenario by noting the scenario must be active, implying this tool is for execution not activation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (on demand) and when not (scenario must be active), with direct reference to make_start_scenario for activation. Also explains wait parameter options and data parameter relevance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the PATCH method, that it modifies real structure, requires confirmed:true (a tool-specific gate not in Make's API), takes a before snapshot and returns it as 'before_blueprint', and states that this is only a recovery aid and does not block or compare. This is thorough transparency.
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 front-loaded with 'HIGH RISK' and the core update action, then details the mandatory workflow and recovery behavior. While somewhat long, every sentence provides essential safety context; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-risk mutation tool with no output schema or annotations, this description covers the safety workflow, the confirmed gate, the before_blueprint recovery mechanism, and the return behavior. It leaves no major gaps for an agent to misuse it.
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 schema already documents all six parameters, but the description adds semantics: confirmed is proof of the approval workflow, and blueprint is optional—omitting it allows partial updates to name/folder/scheduling. This goes beyond the schema's basic 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 states a specific action: updating a scenario's blueprint, scheduling, name, and/or folder via PATCH. It explicitly identifies the resource and scope, and the 'HIGH RISK' warning distinguishes it from read-only siblings like make_get_blueprint. This clearly differentiates it from related 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?
It provides a mandatory workflow: call make_get_blueprint first, present the diff for approval, and prefer testing on a clone via make_clone_scenario. It also explains the confirmed:true requirement as the safety gate, giving explicit when-to-use guidance and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses behavioral traits: it reassures the live scenario is untouched, explains states=true copies module execution state including last trigger position, and default false gives a clean copy. It also discloses fallback logic for team_id/organization_id.
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?
Two sentences, front-loaded with purpose and key safety context, no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the core operation, safety, parameter fallbacks, and states behavior. With no output schema, it might omit return value details, but the essential use context is fully covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds semantics by explaining states behavior with an example ('last trigger position') and clarifying team/org fallback ('configured ones or the single team/org'), going beyond schema 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 states 'Clone a Make.com scenario into a new one with a given name' with a specific verb and resource. It explicitly frames it as 'the safe way to test structural changes' which distinguishes it from mutation tools like make_update_blueprint.
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?
It explicitly says 'the safe way to test structural changes (e.g. before make_update_blueprint) without touching the live scenario,' providing a clear when-to-use. It also clarifies fallback behavior for team_id/organization_id, guiding use in single-org setups.
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 MCP server](https://glama.ai/mcp/servers/yuli-tonkin-bg/make-mcp/badges/card.svg)](https://glama.ai/mcp/servers/yuli-tonkin-bg/make-mcp)

Score Badge

Copy to your README.md:

[![make-mcp MCP server](https://glama.ai/mcp/servers/yuli-tonkin-bg/make-mcp/badges/score.svg)](https://glama.ai/mcp/servers/yuli-tonkin-bg/make-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/yuli-tonkin-bg/make-mcp'

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