Skip to main content
Glama
Moe03

Convocore MCP Server

by Moe03

run_agent_auto_test

Run an automated agent test suite across tools, knowledge base, prompt, or full scenarios to check regressions. Returns testId, status, and score for broader validation than a single-tool test.

Instructions

Start Convocore automated agent test suite (POST /auto-test/run). Modes include tools-only, with-tools, kb-only, full. Returns testId/status/score. Prefer this for broader regression; use test_agent_tool for a single tool.

Input Schema

NameRequiredDescriptionDefault
configNo
agentIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.6.17

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), so the description only needs to add context. It adds that the call returns testId/status/score, which hints at a started job, but never states whether the run is synchronous or async and how to poll for completion, nor what permissions/agent state are required.

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?

Three dense sentences with the core purpose front-loaded and zero filler. The mode enumeration is slightly wasted space given it is both redundant with the enum and incomplete.

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?

With no output schema, the description usefully sketches the return fields (testId/status/score). But for a tool with a nested config of six options and likely long-running behavior, it leaves out async/sync semantics and config field meaning, which are the gaps an agent would actually hit when invoking it.

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 0% and the config object holds six undocumented nested properties, so the description must carry the load. It only partially documents testMode, and even that is incomplete ("tools-only, with-tools, kb-only, full" omits prompt-only and with-kb from the enum); agentId, enableKB, maxTurns, naturalEnd, testScenario and enabledToolIds get no explanation.

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?

States a specific verb and resource ("Start Convocore automated agent test suite") plus the backing endpoint POST /auto-test/run, and names the sibling test_agent_tool it is distinct from. An agent can tell instantly that this runs a full suite rather than a single-tool probe.

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?

Gives an explicit routing rule: "Prefer this for broader regression; use test_agent_tool for a single tool." That is a direct this-vs-alternative selection criterion, which is exactly what an agent needs to choose between the two test tools.

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