Skip to main content
Glama
Moe03

Convocore MCP Server

by Moe03
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

create_agent_tool

Adds an HTTP/API tool to a Convocore agent, letting you define inputs, request mapping, and optional start-node attachment so the model can call it.

Instructions

Add an HTTP/API tool to a Convocore agent. Requires tool.name + tool.description. INPUTS — either (a) tool.variablesIds: ids of existing agent variables (create_agent_variable first), or (b) tool.fields[]: each entry needs key (the argument name — NOT "name"), type (string|number|boolean), in (body|query|header|path), plus description and required. REQUEST — simple tools: method + serverUrl (inputs are sent by their "in" location). Exact request shape: tool.httpRequest = { enabled: true, method, url, headers, query, bodyType: "json", bodyTemplate, bodyTemplateMode: "exact" }. In bodyTemplate/headers/query/url reference a variable with {{var:VARIABLE_ID}}; a value that is only that token keeps its number/boolean type. Fixed values are written literally. SECRETS — store an API key as an environment variable (create_agent_variable with isEnv: true; the value lives in defaultValue) and reference it with {{var:ID}}. Env variables must NOT be listed in variablesIds: they are resolved automatically and never shown to the model. An unfilled optional input sends its defaultValue; an input with no value and no default blocks the call with "Unresolved request values". By default the new tool is attached to the start node (nodes[].toolsIds) so the model can call it; pass attachToStartNode: false to skip. Verify with test_agent_tool_request.

Input Schema

NameRequiredDescriptionDefault
toolYesTool definition: name, description, method, serverUrl, serverUrlSecret, variablesIds[] or fields[] ({key,type,in,description,required}), httpRequest{enabled,method,url,headers,query,bodyType,bodyTemplate,bodyTemplateMode}, channels[], etc.
agentIdYes
attachToStartNodeNoDefault true: adds the new tool id to the start node toolsIds so the agent can call it. A tool that is not in any node toolsIds is never offered to the model.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.6.17

TDQS

A5/5.0
Behavior5/5

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

Annotations already declare this as a non-read-only, open-world, non-idempotent mutation, but the description adds substantial behavioral context: exact httpRequest shape, {{var:ID}} interpolation rules, handling of secrets and environment variables, defaultValue behavior, and the 'Unresolved request values' blocking error. It does not contradict annotations.

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 long but appropriately sized for a complex creation tool with nested request construction. It is front-loaded with purpose and requirements, then organized into INPUTS, REQUEST, SECRETS, and verification guidance; every section earns its place.

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?

Despite the complex nested schema and no output schema, the description covers invocation prerequisites, request construction, secret handling, default behavior, attachment behavior, and verification. It gives an agent everything needed to call the tool correctly.

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

Parameters5/5

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

Schema coverage is only 67% and the tool has nested objects, but the description compensates thoroughly. It explains tool.fields entries (key, type, in, description, required), variablesIds versus fields, httpRequest fields, bodyTemplate mode, variable references, and attachToStartNode semantics far 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 uses a specific verb and resource: 'Add an HTTP/API tool to a Convocore agent.' It also distinguishes this from sibling tools by naming create_agent_variable as a prerequisite for variables and test_agent_tool_request for verification. An agent can identify the operation without opening the schema.

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 states the prerequisite (tool.name + tool.description), the two input modes (variablesIds or fields), and the need to create variables first. It also names the verification tool and explains the default start-node attachment behavior, giving clear when-and-how guidance.

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

Deploy Server

Other Tools