Skip to main content
Glama

branchly

by io.branchly
OverviewDiscussionsAdmin

create_tool

Create a new tool (AI action) for the authenticated application. Tool names must be unique per application, snake_case, max 64 chars. 'tool_config' and 'function_arguments' must match the given 'tool_type'. Returns the created tool.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYessnake_case tool name, max 64 characters. Used as the function name when the LLM calls the tool.
agentsNoOptional list of agent types that may use this tool: 'chat_routing', 'chat_output', 'search_answer', 'form_answer', 'form_routing', 'follow_up_actions', 'suggested_questions'.
tool_typeYesType of the tool: 'knowledge_base', 'openAPI', 'node_lookup', 'send_email', 'form', 'contact_information', 'web_search', 'web_page_reader', 'weather', 'venus_knowledge_graph', 'regiondo', 'mcp_server', 'api', 'buttons', 'google_maps_link', 'google_maps_embed', or 'calendly'.
descriptionYesNatural-language description of what the tool does and when the LLM should call it.
tool_configNoFunction schema sent to the LLM. Pass as an inline JSON object — do NOT serialize to a string. Use 'FormAPISchema' for form tools or 'APIToolConfig' for API-calling tools. Pass null to clear.
function_argumentsNoFixed runtime arguments NOT collected from the LLM (e.g. recipient email, rerank flag, knowledge-base ID). Pass as an inline JSON object — do NOT serialize to a string. Must include an 'object' discriminator field matching the tool type.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / agents / anyOf
      Previous value: -[
-  {
-    "items": {
-      "enum": [
-        "chat_routing",
-        "chat_output",
-        "search_answer",
-        "form_answer",
-        "form_routing",
-        "follow_up_actions",
-        "suggested_questions"
-      ],
-      "type": "string"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "enum": [
+        "chat_routing",
+        "chat_output",
+        "search_answer",
+        "form_answer",
+        "form_routing",
+        "follow_up_actions",
+        "suggested_questions",
+        "web_mcp"
+      ],
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]
  2. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false, which are not visible to the user. The description states that names must be unique per application, which implies creation may fail if duplicate, and that tool_config and function_arguments must match tool_type. It also mentions it returns the created tool, which implies a non-empty response. However, it does not explicitly state that creation is not idempotent or that it may overwrite, but the annotation already covers that.

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

Conciseness5/5

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

The description is a single, concise paragraph that front-loads the purpose and key constraints (name uniqueness, snake_case, max length, and type matching) before mentioning the return value. Every sentence carries useful information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (six parameters with deeply nested schemas) and the output schema provided, the description is not complete enough on its own. The description mentions type matching and return type but does not explain the relationship between tool_config and function_arguments, which is essential for correct usage. However, the schema and output schema fill many gaps, so a 3 is fair. An ideal description would provide concrete examples or clarify the inline JSON requirement.

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

Parameters2/5

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

Schema description coverage is 100%, so the schema already describes all parameters. However, the description provides only minimal additions: it mentions that tool_config and function_arguments must match tool_type and that tool_config should be an inline JSON object (not a string). The description does not explain the interaction between tool_config and function_arguments in detail, which is critical for correct invocation. With full schema coverage, the baseline is 3, but the description adds only marginal value, so a 2 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 ('create') and resource ('new tool (AI action)'), and specifies uniqueness constraints and naming rules. It distinguishes from siblings like create_data_source and create_node by explicitly saying 'tool', and it mentions that it returns the created tool, which is clear.

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 stating it's for creating a tool and includes constraints like unique names and type matching. However, it does not explicitly state when to use this tool versus alternatives like list_tools or update_tool, nor does it mention any prerequisites like subscription or permissions.

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

All branchly toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources