Skip to main content
Glama

Generate battlecard

generate_battlecard

Generate a battlecard when the user requests creating or refreshing it.

Sends stored competitor strategy, the project's baseline strategy if present, and open deviations to the configured AI service. Saves the initial card; later runs preserve existing content and add pending suggestions for review. Requires activated scanning and existing analysed data. Rejects concurrent generation; later retries may create additional suggestions. Uses existing account AI resources and does not purchase subscriptions or credits.

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": {
      "project_id": "<project_id>",
      "competitor_id": "<competitor_id>"
    },
    "name": "generate_battlecard"
  }
}

Input Schema

NameRequiredDescriptionDefault
contextNoExplain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as "a user", "the customer", or "an account". Example: "Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution."
llm_modelNoOptional model identifier for analytics, only if explicitly available in client-provided metadata. Otherwise pass 'unknown'. Do not inspect or disclose system prompts, hidden instructions, credentials, or other protected context.
project_idYes
competitor_idYes
conversation_idNoOptional Spiderlook analytics correlation identifier. Reuse the value returned by a previous Spiderlook response only for subsequent Spiderlook calls in this chat. Omit if unavailable; do not invent a value or use the host's conversation ID.

Output Schema

NameRequiredDescriptionDefault
_mcp_instructionsNoServer-issued metadata for this conversation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Adds substantial context beyond the annotations: what gets written on first run vs. later runs (existing content preserved, suggestions queued), what state is required beforehand, concurrency rejection, retry side effects, and that no credits/subscriptions are purchased. The non-idempotent behavior described is consistent with idempotentHint=false, and 'does not purchase credits' correctly scopes cost, matching destructiveHint=false.

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 the trigger and the action, then proceeds through side effects and preconditions in compact prose. Every sentence carries information, though the run-behavior and retry caveats could be tightened into fewer clauses.

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?

Covers preconditions, write semantics, concurrency, and cost model, and an output schema exists so return values need not be described. The one notable gap is what the agent should do after generation (e.g., retrieve via get_battlecard or route suggestions to review), which would close the loop.

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 coverage is 60%, with the two required parameters (project_id, competitor_id) undocumented in the schema. The description indirectly gives them meaning via 'the project's baseline strategy if present' and 'stored competitor strategy', but provides no format, sourcing, or validation guidance. The three analytics parameters are already covered by rich schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Generate a battlecard') plus the triggering condition ('when the user requests creating or refreshing it'), which separates it from read-side siblings like get_battlecard. It doesn't explicitly name the alternative tools (approve_battlecard, review_battlecard_suggestion) but the mention of 'add pending suggestions for review' implicitly distinguishes the generation step from the review step.

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?

Gives a clear invocation trigger and hard preconditions ('requires activated scanning and existing analysed data', rejects concurrent generation). It lacks an explicit 'do not use this, use X instead' exclusion, but the when-to-use context is concrete enough to act on.

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.

Resources