Skip to main content
Glama

TestChimp

by io.testchimp
OverviewDiscussionsAdmin

Create User Story

create-user-story

Create a user story on the TestChimp project and allocate a real US-. Response includes content: canonical stub markdown already containing id: US-. BLOCKING workflow: call this FIRST → Write the returned content to the repo plans/stories path (edit body as needed but keep id:) → call update-user-story with the full markdown. Never write story markdown that omits id. platformFilePath must be under plans/stories/ and end with .md. Optional agentTraceability (or flat workflowId/workflowExecutionId/policyFile/policyVersion/gitSha/…) records AGENT_WORKFLOW_ACTIVITY inline — no separate report-agent-action needed for this create.

Input Schema

NameRequiredDescriptionDefault
botIdNoQA bots: your botId from your stored TestChimp binding.
titleYes
gitShaNo
userIdNo
actorTypeNo
agentModelNo
branchNameNo
cliVersionNo
policyFileNo
workflowIdNo
skillVersionNo
policyVersionNo
projectApiKeyNoQA bots: your own project API key from your stored TestChimp binding. Required on every call except get-bot-credentials, get-project-credentials and get-bot-compat. Never print it.
platformFilePathYes
agentTraceabilityNo
workflowExecutionIdNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / botId
      Added value: +{
+  "description": "QA bots: your botId from your stored TestChimp binding.",
+  "maxLength": 64,
+  "minLength": 1,
+  "type": "string"
+}
    • addedInput schema / properties / projectApiKey
      Added value: +{
+  "description": "QA bots: your own project API key from your stored TestChimp binding. Required on every call except get-bot-credentials, get-project-credentials and get-bot-compat. Never print it.",
+  "maxLength": 256,
+  "minLength": 8,
+  "type": "string"
+}
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the bar is lower. The description adds genuinely useful behavior beyond that: the response carries a canonical stub with an id that must be preserved, platformFilePath must live under plans/stories/ and end in .md, and AGENT_WORKFLOW_ACTIVITY is recorded inline so no separate report-agent-action call is needed.

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?

Front-loaded with purpose, then the blocking workflow, then path/id constraints. Dense but every clause carries actionable content; minor density in the long traceability sentence keeps it from a 5.

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 non-idempotent mutation with annotations and no output schema, the description covers the workflow sequence, the returned content shape, the id-preservation rule, and the path constraint. It omits error/failure behavior and auth prerequisites, but the critical call-correctly information is present.

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 description coverage is only 13% across 16 params, so the description must carry weight. It documents the two required params' constraints (platformFilePath path rules) and explains that agentTraceability is a nested alternative to the flat workflowId/workflowExecutionId/gitSha/... fields, but the bulk of params (botId, projectApiKey, actorType, versions) remain unexplained.

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 (create a user story), names the project, and reveals the distinguishing side effect: allocation of a real US-<ordinalId> and return of canonical stub markdown. An agent can immediately separate this from get-user-stories and update-user-story.

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?

The blocking workflow is spelled out explicitly: call this FIRST, write the returned content to the plans/stories path, then call update-user-story with the full markdown. It also states the exclusion rule (never write story markdown that omits id) and routes the agent to the correct follow-up sibling.

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

All TestChimp toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources