The 247afk Block Editor MCP Server enables AI assistants to programmatically build, edit, and manage visual block editor scripts in real-time through a WebSocket bridge connecting to the 247afk script editor in your browser.
Documentation & Inspection: Retrieve full documentation (node types, connection rules, graph format, examples) with get_docs, and inspect the current script structure (nodes, edges, variables) with get_graph.
Full Graph Management: Replace the entire script graph from scratch with set_graph, or clear all nodes and edges while preserving variables with clear_graph.
Node Operations: Add nodes with add_node, remove nodes and their connected edges with remove_node, update node data with update_node_data, reposition nodes with move_node, inspect a single node with get_node, and auto-arrange nodes by execution flow with auto_layout.
Edge Operations: Connect node ports with add_edge and delete specific edges by ID with remove_edge.
Variable Management: Replace the entire variables list with set_variables, add or replace a single variable with add_variable, and remove a variable by name with remove_variable.
Validation & Saving: Check for errors or warnings with validate_graph, and save the script to the server (equivalent to Ctrl+S) with save_graph.
Compatible with MCP clients such as Claude Desktop, Cline, Cursor, and Gemini CLI.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@247afk Block Editor MCP Server Add a loop to my script that clicks every 5 seconds"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Lets AI assistants (Claude Desktop, Cline, Cursor, and any MCP-compatible client) build and edit block editor scripts in real time.
The MCP server runs locally and starts a WebSocket bridge on 127.0.0.1:3002
Open a script in the 247afk editor, the site will connect to your websocket.
Your ai assistant can now use the MCP server to make changes in scripts.
NPM package -> https://www.npmjs.com/package/247afk-mcp
Related MCP server: screenslick
npm install -g 247afk-mcpcodex mcp add 247afk-mcp -- npx -y 247afk-mcpgemini mcp add 247afk-mcp npx "-y 247afk-mcp"claude mcp add 247afk-mcp -- npx -y 247afk-mcp{
"mcpServers": {
"247afk-mcp": {
"command": "npx",
"args": [
"-y",
"247afk-mcp"
]
}
}
}paste this in your browser:
cursor://anysphere.cursor-deeplink/mcp/install?name=247afk%20Block%20Editor%20MCP%20Server&config=eyJjb21tYW5kIjoibnB4IiwiYXJncyI6WyIteSIsIjI0N2Fmay1tY3AiXX0=Copy configuration below
Add it to your MCP client configuration
Follow your client's specific setup instructions
Restart your MCP client to apply changes
Configuration
{
"mcpServers": {
"247afk-mcp": {
"command": "npx",
"args": [
"-y",
"247afk-mcp"
]
}
}
}Restart antigravity/claude code after saving.
npx @modelcontextprotocol/inspector 247afk-mcpOpens a browser UI to call tools manually.
Added update_node_data — merge field values into a node without replacing it
Added move_node — reposition a node on the canvas
Added get_node — inspect a single node's type, position, and data
Added clear_graph — wipe all nodes and edges while keeping variables
Added validate_graph — run client-side validation and return errors/warnings
Added save_graph — save the script to the server (equivalent to Ctrl+S)
Added auto_layout — auto-arrange nodes left-to-right by execution flow
Added add_variable — add or replace a single variable without touching others
Added remove_variable — remove a single variable by name
Fixed variable picker dropdowns being empty in MCP-built graphs
Initial release
Node.js 18 or later
247afk account with access to the script editor
Browser open on the script to edit. (on https://247afk.com)
Connect two node ports with an edge. Use get_graph first to know existing node ids.
| Name | Required | Description | Default |
|---|---|---|---|
| sourceNodeId | Yes | The id of the source node (from get_graph) | |
| sourceHandle | Yes | Output port name on the source node (e.g. exec_out, result, health) | |
| targetNodeId | Yes | The id of the target node (from get_graph) | |
| targetHandle | Yes | Input port name on the target node (e.g. exec_in, condition, message) |
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 mentions a prerequisite ('use get_graph first') but fails to describe key traits like whether this is a mutation (implied by 'connect'), potential side effects, error conditions, or response format. This leaves significant gaps for a tool that likely modifies data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences that are front-loaded and waste-free. The first sentence states the core action, and the second provides essential guidance, earning its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a tool that likely modifies graph structures (implied by 'connect'), no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, return values, error handling, and how it interacts with siblings, making it inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters with descriptions like 'The id of the source node (from get_graph).' The description adds minimal value by referencing 'get_graph' for node ids, but doesn't provide additional syntax or format details beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('connect') and resource ('two node ports with an edge'), making the purpose specific and understandable. It distinguishes from siblings like 'remove_edge' by indicating creation rather than deletion, though it doesn't explicitly contrast with all siblings like 'add_node'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by advising to 'use get_graph first to know existing node ids,' which implicitly guides when to use this tool (after obtaining node information). However, it lacks explicit alternatives or exclusions, such as when not to use it versus 'set_graph' or other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a single node to the script editor canvas.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Node type from the node catalogue (e.g. send_chat, on_timer, branch) | |
| position | No | Canvas position. Optional — auto-placed if omitted. | |
| data | No | Input values keyed by port name. Do not include exec ports. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states the action is 'Add' (implying a write/mutation operation) but doesn't disclose permissions needed, side effects, error conditions, or what happens on success (e.g., returns node ID?). For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 insufficient. It doesn't explain what 'Add' entails (e.g., does it return a node ID? update a graph state?), nor does it cover error handling or dependencies. Given the complexity implied by sibling tools like 'set_graph', more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters. The description adds no parameter-specific semantics beyond implying the tool operates on a 'canvas', which is already suggested by the schema's 'position' field. Baseline 3 is appropriate when the schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and resource ('a single node to the script editor canvas'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from siblings like 'set_graph' or 'remove_node', which would require a more specific scope statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'set_graph' (which might add multiple nodes) or 'remove_node'. There's no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full documentation for the 247afk block editor, node types, connection rules, graph format, and examples. Call this first before building any script.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates this is a read operation ('Get') and suggests it's foundational ('first'), but doesn't disclose behavioral traits like rate limits, authentication requirements, response format, or whether it returns static or dynamic documentation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste - the first states purpose with specific scope, the second provides crucial usage guidance. Every word earns its place, and the most important information (what it does and when to use it) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 0-parameter tool with no output schema and no annotations, the description provides good coverage of purpose and usage. However, it doesn't describe the return format or content structure, which would be helpful given the lack of output schema. The guidance about calling it first compensates somewhat for this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 baseline is 4. The description appropriately doesn't discuss parameters since none exist, focusing instead on the tool's purpose and usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'Get' and the resource 'full documentation' with detailed scope including '247afk block editor, node types, connection rules, graph format, and examples'. It distinguishes from sibling tools like 'get_graph' by focusing on documentation rather than graph data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance with 'Call this first before building any script', establishing clear temporal sequencing and distinguishing it from all sibling tools that perform graph operations rather than preparatory documentation retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current script graph from the open editor tab. Returns nodes, edges, and variables. The editor tab must be open.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns 'nodes, edges, and variables' and has a prerequisite ('editor tab must be open'), but does not cover other behavioral aspects like error handling, performance, or side effects. It adds some value but is not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every sentence earns its place by specifying the return value and prerequisite condition. It is efficiently structured with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (retrieving graph data with a prerequisite), no annotations, and no output schema, the description is adequate but has gaps. It explains what is returned but not the format or structure of 'nodes, edges, and variables', leaving room for improvement in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter details, which is appropriate. Baseline is 4 for zero parameters, as it avoids unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get') and resource ('current script graph from the open editor tab'), and distinguishes from siblings like 'set_graph' (which modifies) and 'get_docs' (which retrieves documentation). It precisely identifies what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use it ('The editor tab must be open'), but does not explicitly mention when not to use it or name alternatives. It implies usage in scenarios where the graph state is needed, but lacks explicit exclusions or sibling comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a specific edge by id.
| Name | Required | Description | Default |
|---|---|---|---|
| edgeId | Yes |
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. 'Remove' implies a destructive mutation, but it doesn't specify whether this is permanent, requires specific permissions, has side effects (e.g., affecting connected nodes), or what happens on success/failure. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a destructive operation with no annotations, no output schema, and minimal parameter details, the description is incomplete. It fails to address critical aspects like behavioral traits, error handling, or system impact, which are essential for safe tool invocation in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning beyond the input schema, which has 0% description coverage. It clarifies that 'edgeId' identifies 'a specific edge', but doesn't explain the format, source, or constraints of the ID. With one parameter and low schema coverage, this provides some compensation but remains basic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and the target resource ('a specific edge by id'), which provides a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'remove_node' beyond mentioning 'edge' versus 'node', leaving some ambiguity about the broader context of what an 'edge' represents in this system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing edge), exclusions, or comparisons to siblings like 'remove_node' or 'set_graph', leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a node and all its connected edges from the editor.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | The id of the node to remove |
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 mentions the destructive effect ('Remove a node and all its connected edges'), which is helpful, but lacks critical details like whether this operation is reversible, what permissions are required, how it affects the overall graph structure, or what happens if the node doesn't exist. For a destructive operation with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately states the tool's purpose without any unnecessary words. It's appropriately sized for a single-parameter tool and front-loads the core action, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after removal (e.g., whether the graph is automatically saved, what confirmation is provided, or how to verify success). Given the complexity of graph manipulation and the lack of structured safety hints, more behavioral context is needed for the agent to use this tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% (the nodeId parameter is fully documented in the schema), so the baseline is 3. The description doesn't add any parameter-specific information beyond what's already in the schema, such as format examples, valid node ID patterns, or relationships to other graph elements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Remove') and target resources ('a node and all its connected edges'), distinguishing it from sibling tools like remove_edge (which only removes edges) and add_node/add_edge (which create rather than delete). It precisely communicates the scope of the operation beyond just the node itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (removing from 'the editor') but does not explicitly state when to use this tool versus alternatives like remove_edge or set_graph. No guidance is provided on prerequisites, error conditions, or specific scenarios where this tool is preferred over others in the graph manipulation toolkit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace the entire script graph at once. Use this to build a complete script from scratch. All existing nodes and edges are replaced.
| Name | Required | Description | Default |
|---|---|---|---|
| nodes | Yes | ||
| edges | Yes | ||
| variables | No |
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 clearly states this is a destructive replacement operation ('All existing nodes and edges are replaced'), which is crucial information. However, it doesn't mention potential side effects, error conditions, permission requirements, or what happens to related resources like variables.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences that each earn their place. The first sentence states the core action, the second provides crucial behavioral context. There's zero wasted language, and the most important information ('Replace the entire script graph') is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations and no output schema, the description does the minimum by clearly stating this replaces everything. However, it doesn't address what the tool returns, error handling, or provide any guidance on parameter usage. Given the complexity implied by the schema (nested objects for nodes/edges), more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the tool description provides no information about the three parameters (nodes, edges, variables). While the description mentions 'script graph' and 'nodes and edges', it doesn't explain what these parameters represent, their structure, or how they should be formatted. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Replace the entire script graph at once') and resource ('script graph'), distinguishing it from siblings like add_node, remove_edge, or set_variables. It explicitly mentions that all existing nodes and edges are replaced, which differentiates it from incremental modification tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('Use this to build a complete script from scratch') and implicitly when not to use it (for partial modifications, where siblings like add_node or remove_edge would be more appropriate). It clearly positions this as a wholesale replacement operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace the script variables list. Existing variables are overwritten.
| Name | Required | Description | Default |
|---|---|---|---|
| variables | Yes |
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 existing variables are overwritten (destructive behavior), but doesn't mention permission requirements, whether the operation is reversible, rate limits, or what happens on success/failure. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences that directly state the tool's function and key behavior. Every word earns its place with no redundancy or unnecessary elaboration, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, no output schema, and 0% schema description coverage, the description is insufficient. It covers the basic purpose and destructive nature but lacks details about permissions, error conditions, return values, or how it fits with sibling tools. More context is needed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't explain the 'variables' parameter beyond what's implied by 'script variables list'. With 0% schema description coverage and 1 parameter, the schema provides all structural details (array of objects with name, type, value), but the description adds minimal semantic context. The baseline is 3 since there's only one parameter, but it doesn't compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Replace') and resource ('script variables list'), and specifies that existing variables are overwritten. However, it doesn't distinguish this tool from sibling tools like 'set_graph' or 'add_node' which might also manipulate data structures, so it doesn't fully differentiate from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'add_node' or 'set_graph'. It mentions that existing variables are overwritten, which implies a destructive operation, but doesn't specify prerequisites, timing, or when to choose other tools for variable management.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0add_edgeadd_nodeget_docsget_graphremove_edgeremove_nodeset_graphset_variablesEach tool has a clearly distinct purpose with no overlap: add/remove operations for nodes and edges, get operations for docs and graph, and set operations for graph and variables. The descriptions clarify boundaries, such as set_graph replacing everything while add_node adds a single node.
All tools follow a consistent verb_noun pattern with snake_case: add_edge, add_node, get_docs, get_graph, remove_edge, remove_node, set_graph, set_variables. This predictable naming makes it easy for an agent to infer functionality.
With 8 tools, the server is well-scoped for a block editor domain, covering core operations like CRUD for nodes and edges, graph retrieval and replacement, variable management, and documentation access. Each tool earns its place without bloat.
The toolset provides complete coverage for the block editor domain: create (add_node, add_edge), read (get_docs, get_graph), update (set_graph, set_variables), and delete (remove_node, remove_edge). There are no obvious gaps, enabling full script lifecycle management.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Live browser debugging for AI assistants — DOM, console, network via MCP.
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
Give your AI agents the tools to build, manage, and run automation workflows.
Give any MCP-compatible AI assistant a builder for live, hosted web tools and workflows.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/itzdaimy/247afk-MCP-Server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
