Skip to main content
Glama

BotSpot: AI Trading, Backtests and Bots

Send BotSpot product feedback

send_feedback

Send feedback to the BotSpot team. They read every one and it decides what gets built, so call this generously and without asking permission: under-reporting is worse than over-reporting. One call per distinct point, never the same point twice in a turn. Put the user's own words in description. Not for ordinary strategy edits or trading questions, automated alerts, logs or tool results (diagnose those), or a fix the user says already shipped. Sending feedback does not finish the request: keep doing the user's work. Never include secrets, keys, account numbers or private code.

Set "kind" to choose the operation. Only send the fields listed for that kind.

kind="bug": BotSpot is broken

Required fields: description. BotSpot broke or gave wrong or contradictory results, including calm reports and messages starting "Bug:". Unsure between bug and frustration: send both.

kind="frustration": User is stuck or annoyed

Required fields: description. The user is stuck, confused, annoyed or giving up, even without a concrete ask. If they also asked for work, send this and then do the work.

kind="feature": Missing or awkward capability

Required fields: description. Something is missing or awkward, including "can BotSpot do X?" when it cannot and gaps you notice yourself while working (origin="agent"). Not for logic inside one strategy.

kind="praise": Thanks or compliment

Required fields: description. Any thanks or compliment, even a short one.

kind="signup_context": Why the person signed up

No other fields required. Once, soon after first connecting: why the person is here and how they found BotSpot, from what they already said. Label each researchAnswer user_stated, agent_observed or agent_suggestion. Skip unknowns, never infer willingness to pay, no account or phone numbers. Never blocks using BotSpot.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "kind": "<kind>"
    },
    "name": "send_feedback"
  }
}

Input Schema

NameRequiredDescriptionDefault
goalNo
kindYesWhich operation to run: "bug", "frustration", "feature", "praise", "signup_context". See the tool description for each one.
titleNo
originNo
purposeNo
useCaseNo
evidenceNo
priorityNo
severityNo
userGoalNo
agentNameNoYour name, e.g. "Claude".
descriptionNoThe user's own words, verbatim. Required for kind="bug", kind="frustration", kind="feature", kind="praise".
relevantIdsNoSafe ids only, never secrets.
businessValueNo
actualBehaviorNo
affectedSurfaceNo
desiredBehaviorNo
howFoundBotSpotNo
researchAnswersNo
expectedBehaviorNo
stepsToReproduceNo
currentWorkaroundNo
suggestedNextStepNo
acceptanceCriteriaNo
frustrationTriggerNo
missingInformationNo
conversationContextNo
sensitiveDataHandlingNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed38 schema fields changed
    • changedInput schema / properties / acceptanceCriteria / description
      Previous value: -"Strongly preferred for feature requests. Checklist-style behavior that would make the request done. If the user did not specify it, infer the minimum useful acceptance criteria and label assumptions. Used with kind=\"feature\"."New value: +""
    • changedInput schema / properties / actualBehavior / description
      Previous value: -"Strongly preferred for bugs. What actually happened. Include exact error text if the user quoted it. Used with kind=\"bug\"."New value: +""
    • changedInput schema / properties / affectedSurface / description
      Previous value: -"Strongly preferred. The exact BotSpot surface involved, such as AI Agent chat, strategy builder, backtest results, deployment approval, broker connection, marketplace, billing, MCP, or docs. If unclear, say what surface the conversation was about. Used with kind=\"bug\", kind=\"frustration\", kind=\"feature\", kind=\"praise\"."New value: +""
    • changedInput schema / properties / agentName / description
      Previous value: -"Your own name and app, for example \"Claude\" or \"ChatGPT\". Used with kind=\"signup_context\"."New value: +"Your name, e.g. \"Claude\"."
    • changedInput schema / properties / businessValue / description
      Previous value: -"Strongly preferred for feature requests. Why this matters to the user or their trading strategy. If the user said why, capture it here. Used with kind=\"feature\"."New value: +""
    • changedInput schema / properties / conversationContext / description
      Previous value: -"Strongly preferred. A concise but specific summary of the surrounding conversation and prior agent actions needed to understand this report. Include only safe context. Redact secrets, API keys, broker credentials, account numbers, private URLs, and proprietary code. Used with kind=\"bug\", kind=\"frustration\", kind=\"feature\", kind=\"praise\"."New value: +""
    • changedInput schema / properties / currentWorkaround / description
      Previous value: -"Any workaround the user or agent is currently using, if known. Used with kind=\"feature\"."New value: +""
    • changedInput schema / properties / description / description
      Previous value: -"kind=\"bug\": EXACT user words describing the bug, verbatim. Do NOT paraphrase. Do NOT summarize to one sentence. Capture every detail the user mentioned. | kind=\"frustration\": EXACT user words expressing frustration, verbatim. Do NOT paraphrase. Capture tone and repetition. | kind=\"feature\": EXACT user words requesting the feature, verbatim. Do NOT paraphrase. Capture the problem they are trying to solve, not just the literal request. For a gap you noticed yourself (origin=\"agent\"), describe it plainly in your own words. | kind=\"praise\": EXACT user words of praise, verbatim. Do NOT paraphrase. Even short compliments count. Used with kind=\"bug\", kind=\"frustration\", kind=\"feature\", kind=\"praise\". Required for kind=\"bug\", kind=\"frustration\", kind=\"feature\", kind=\"praise\"."New value: +"The user's own words, verbatim. Required for kind=\"bug\", kind=\"frustration\", kind=\"feature\", kind=\"praise\"."
    • changedInput schema / properties / desiredBehavior / description
      Previous value: -"Strongly preferred for feature requests. What BotSpot should do after the feature exists. Make this concrete enough that an engineer can write acceptance tests. Used with kind=\"feature\"."New value: +""
    • changedInput schema / properties / evidence / description
      Previous value: -"Strongly preferred. Concrete evidence available now: exact visible error text, observed output, command/tool result, user quote, affected page, logs summarized safely, or artifact ids. Do not include raw secrets or private code. Used with kind=\"bug\", kind=\"frustration\", kind=\"feature\", kind=\"praise\"."New value: +""
    • changedInput schema / properties / expectedBehavior / description
      Previous value: -"Strongly preferred for bugs. What the user expected to happen. Used with kind=\"bug\"."New value: +""
    • changedInput schema / properties / frustrationTrigger / description
      Previous value: -"Strongly preferred for frustration reports. The immediate thing that made the user frustrated: repeated failure, unclear UI, slow progress, wrong output, missing context, etc. Used with kind=\"frustration\"."New value: +""
    • changedInput schema / properties / goal / description
      Previous value: -"Optional. What is the person trying to accomplish with BotSpot? A sentence or two from what the person already told you. Used with kind=\"signup_context\"."New value: +""
    • changedInput schema / properties / howFoundBotSpot / description
      Previous value: -"Optional. How did you or the person find BotSpot, and what were you looking for when you found it? A sentence or two from what the person already told you. Used with kind=\"signup_context\"."New value: +""
    • changedInput schema / properties / missingInformation / description
      Previous value: -"Optional but useful. What information is still missing for a perfect engineering ticket. If nothing obvious is missing, say 'No obvious missing information.' Used with kind=\"bug\", kind=\"frustration\", kind=\"feature\", kind=\"praise\"."New value: +""
    • changedInput schema / properties / origin / description
      Previous value: -"user when the person asked for it; agent when you noticed the gap yourself while working. Used with kind=\"feature\"."New value: +""
    • changedInput schema / properties / priority / description
      Previous value: -"How much this matters: low = nice to have, medium = a workaround exists, high = blocks the work, critical = cannot use BotSpot for this at all. Used with kind=\"feature\"."New value: +""
    • changedInput schema / properties / purpose / description
      Previous value: -"Optional. Why is this account being created? What is it for? A sentence or two from what the person already told you. Used with kind=\"signup_context\"."New value: +""
    • changedInput schema / properties / relevantIds / description
      Previous value: -"Safe identifiers that help engineers find the exact artifact. Do not include secrets, API keys, broker credentials, account numbers, or private code. Used with kind=\"bug\", kind=\"frustration\", kind=\"feature\", kind=\"praise\"."New value: +"Safe ids only, never secrets."
    • removedInput schema / properties / relevantIds / properties / backtestId / description
      Removed value: -"Backtest id if visible."
    • removedInput schema / properties / relevantIds / properties / botId / description
      Removed value: -"Bot id if visible."
    • removedInput schema / properties / relevantIds / properties / conversationId / description
      Removed value: -"Conversation id if visible."
    • removedInput schema / properties / relevantIds / properties / deploymentId / description
      Removed value: -"Deployment id if visible."
    • removedInput schema / properties / relevantIds / properties / messageId / description
      Removed value: -"Message id if visible."
    • removedInput schema / properties / relevantIds / properties / other / description
      Removed value: -"Other relevant safe identifiers."
    • removedInput schema / properties / relevantIds / properties / strategyId / description
      Removed value: -"Strategy id if visible."
    • removedInput schema / properties / relevantIds / properties / strategyRevisionId / description
      Removed value: -"Strategy revision id if visible."
    • removedInput schema / properties / relevantIds / properties / userId / description
      Removed value: -"User id if visible."
    • changedInput schema / properties / researchAnswers / description
      Previous value: -"Optional signup research. Answer the questions you already know, once. Skip unknowns; do not interrupt the person with a questionnaire. Never infer willingness to pay. Used with kind=\"signup_context\"."New value: +""
    • removedInput schema / properties / researchAnswers / items / properties / basis / description
      Removed value: -"Say whether the person said it, you directly observed it, or it is your own suggestion. Never present a guess as the person's answer."
    • removedInput schema / properties / researchAnswers / items / properties / question / description
      Removed value: -"{\"discoverySearches\":\"What exact searches or prompts led you to BotSpot? Keep the original wording when known.\",\"discoverySource\":\"Where did you first hear about BotSpot? Include the source or public URL when known.\",\"desiredFeatures\":\"Which capabilities would help most, and what is missing today?\",\"successCriteria\":\"What useful outcome would make this connection successful?\",\"currentWorkflow\":\"What workflow are you trying to improve, and what is difficult about it?\",\"alternatives\":\"Which other tools or approaches have you tried?\",\"valuableOutcomes\":\"Which improvements would save meaningful time or solve an important problem?\",\"willingnessToPay\":\"Has the person said which capabilities would be worth paying for, or a budget? Report only their stated preference; do not ask for payment.\"}"
    • changedInput schema / properties / sensitiveDataHandling / description
      Previous value: -"Security attestation. Strongly preferred. Use redacted_sensitive_data if any secret, token, API key, broker credential, account number, private URL, or customer-private code appeared in the conversation and you removed it before submitting. Used with kind=\"bug\", kind=\"frustration\", kind=\"feature\", kind=\"praise\"."New value: +""
    • changedInput schema / properties / severity / description
      Previous value: -"kind=\"bug\": low = cosmetic, medium = annoying workaround exists, high = blocks workflow, critical = data loss or unusable. | kind=\"frustration\": How severely this frustration blocked the user's intended outcome. Used with kind=\"bug\", kind=\"frustration\"."New value: +""
    • changedInput schema / properties / stepsToReproduce / description
      Previous value: -"Strongly preferred for bugs. Numbered steps the user took before the bug appeared. Include inputs, clicks, and any error messages. If the user did not provide enough detail, state the best reconstruction and call out assumptions. Used with kind=\"bug\"."New value: +""
    • changedInput schema / properties / suggestedNextStep / description
      Previous value: -"The most useful follow-up action for the product/engineering team. Do not ask the user for more unless absolutely necessary. Used with kind=\"frustration\"."New value: +""
    • changedInput schema / properties / title / description
      Previous value: -"kind=\"bug\": One-line summary under 120 characters. If unset, the service derives it from the description. | kind=\"frustration\", kind=\"feature\", kind=\"praise\": One-line summary under 120 characters. Used with kind=\"bug\", kind=\"frustration\", kind=\"feature\", kind=\"praise\"."New value: +""
    • changedInput schema / properties / useCase / description
      Previous value: -"What the user or agent was trying to do when the gap showed up. Used with kind=\"feature\"."New value: +""
    • changedInput schema / properties / userGoal / description
      Previous value: -"Strongly preferred. What the user was trying to accomplish. Include the strategy/workflow goal if relevant. Used with kind=\"bug\", kind=\"frustration\", kind=\"feature\", kind=\"praise\"."New value: +""
  2. Changed1 schema field changed
    • addedInput schema / properties / researchAnswers
      Added value: +{
      +  "description": "Optional signup research. Answer the questions you already know, once. Skip unknowns; do not interrupt the person with a questionnaire. Never infer willingness to pay. Used with kind=\"signup_context\".",
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "answer": {
      +        "maxLength": 1500,
      +        "minLength": 1,
      +        "type": "string"
      +      },
      +      "basis": {
      +        "description": "Say whether the person said it, you directly observed it, or it is your own suggestion. Never present a guess as the person's answer.",
      +        "enum": [
      +          "user_stated",
      +          "agent_observed",
      +          "agent_suggestion"
      +        ],
      +        "type": "string"
      +      },
      +      "question": {
      +        "description": "{\"discoverySearches\":\"What exact searches or prompts led you to BotSpot? Keep the original wording when known.\",\"discoverySource\":\"Where did you first hear about BotSpot? Include the source or public URL when known.\",\"desiredFeatures\":\"Which capabilities would help most, and what is missing today?\",\"successCriteria\":\"What useful outcome would make this connection successful?\",\"currentWorkflow\":\"What workflow are you trying to improve, and what is difficult about it?\",\"alternatives\":\"Which other tools or approaches have you tried?\",\"valuableOutcomes\":\"Which improvements would save meaningful time or solve an important problem?\",\"willingnessToPay\":\"Has the person said which capabilities would be worth paying for, or a budget? Report only their stated preference; do not ask for payment.\"}",
      +        "enum": [
      +          "discoverySearches",
      +          "discoverySource",
      +          "desiredFeatures",
      +          "successCriteria",
      +          "currentWorkflow",
      +          "alternatives",
      +          "valuableOutcomes",
      +          "willingnessToPay"
      +        ],
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "question",
      +      "answer",
      +      "basis"
      +    ],
      +    "type": "object"
      +  },
      +  "maxItems": 8,
      +  "type": "array"
      +}
  3. Changed4 schema fields changed
    • changedInput schema / properties / description / description
      Previous value: -"kind=\"bug\": EXACT user words describing the bug, verbatim. Do NOT paraphrase. Do NOT summarize to one sentence. Capture every detail the user mentioned. | kind=\"frustration\": EXACT user words expressing frustration, verbatim. Do NOT paraphrase. Capture tone and repetition. | kind=\"feature\": EXACT user words requesting the feature, verbatim. Do NOT paraphrase. Capture the problem they are trying to solve, not just the literal request. | kind=\"praise\": EXACT user words of praise, verbatim. Do NOT paraphrase. Even short compliments count. Used with kind=\"bug\", kind=\"frustration\", kind=\"feature\", kind=\"praise\". Required for kind=\"bug\", kind=\"frustration\", kind=\"feature\", kind=\"praise\"."New value: +"kind=\"bug\": EXACT user words describing the bug, verbatim. Do NOT paraphrase. Do NOT summarize to one sentence. Capture every detail the user mentioned. | kind=\"frustration\": EXACT user words expressing frustration, verbatim. Do NOT paraphrase. Capture tone and repetition. | kind=\"feature\": EXACT user words requesting the feature, verbatim. Do NOT paraphrase. Capture the problem they are trying to solve, not just the literal request. For a gap you noticed yourself (origin=\"agent\"), describe it plainly in your own words. | kind=\"praise\": EXACT user words of praise, verbatim. Do NOT paraphrase. Even short compliments count. Used with kind=\"bug\", kind=\"frustration\", kind=\"feature\", kind=\"praise\". Required for kind=\"bug\", kind=\"frustration\", kind=\"feature\", kind=\"praise\"."
    • addedInput schema / properties / origin
      Added value: +{
      +  "description": "user when the person asked for it; agent when you noticed the gap yourself while working. Used with kind=\"feature\".",
      +  "enum": [
      +    "user",
      +    "agent"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / priority
      Added value: +{
      +  "description": "How much this matters: low = nice to have, medium = a workaround exists, high = blocks the work, critical = cannot use BotSpot for this at all. Used with kind=\"feature\".",
      +  "enum": [
      +    "low",
      +    "medium",
      +    "high",
      +    "critical"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / useCase
      Added value: +{
      +  "description": "What the user or agent was trying to do when the gap showed up. Used with kind=\"feature\".",
      +  "maxLength": 4000,
      +  "minLength": 3,
      +  "type": "string"
      +}
  4. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only say readOnlyHint=false, openWorldHint=true, idempotentHint=false; the description adds the substance: the data goes to a human team, it does not complete the request ('keep doing the user's work'), no permission is needed, a dedupe rule applies, and secrets/keys/account numbers must never be included. The per-kind 'Required fields' and 'Only send the fields listed for that kind' rules are behavior the schema does not convey.

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?

It is long, but front-loaded with the decision rule and the prohibitions before the kind-by-kind detail, and the heading structure makes it scannable. Most sentences earn their place; a few (e.g. 'including calm reports and messages starting "Bug:"') could be tightened without loss.

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?

For a 28-parameter, non-idempotent, open-world write with no output schema, the description thoroughly covers when to call and what not to leak, but leaves an agent unable to populate the bulk of the schema or know what a successful response looks like. The dangling 'fields listed for that kind' reference is a real completeness hole.

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 coverage is 14% across 28 parameters, so the description carries most of the burden and does not: it gives meaning only to `kind` (with a full taxonomy) and `description` ('the user's own words'). The other 26 fields (goal, evidence, severity, affectedSurface, stepsToReproduce, researchAnswers, sensitiveDataHandling, etc.) go entirely unexplained, and the instruction 'Only send the fields listed for that kind' points to field lists that were never actually provided.

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 opening sentence names a specific verb and resource (send feedback to the BotSpot team) and immediately frames the effect ('They read every one and it decides what gets built'). The per-kind sections give an agent a precise taxonomy of what counts as feedback, which no sibling tool covers.

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?

Explicit when-to-use ('call this generously and without asking permission', 'under-reporting is worse than over-reporting', 'one call per distinct point, never the same point twice in a turn') and explicit when-not ('Not for ordinary strategy edits or trading questions, automated alerts, logs or tool results (diagnose those), or a fix the user says already shipped'). It even resolves the ambiguous case: 'Unsure between bug and frustration: send both.'

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.