Skip to main content
Glama

Competitive Intel

competitive_intel
Read-only

Helps you decide how to win against each competitor: it takes your product and the competitors you name, and returns one battle card per competitor built from your strengths, weaknesses, competitor details, objections, wins and losses. Each competitor detail goes to the competitor it names, each objection gets its own answer, and strengths and gaps taken from wins and losses stay in your own words.

Input Schema

NameRequiredDescriptionDefault
industryNoOptional: your own company's sector, so the answer uses the usual buyers, measures and objections for what you sell. Leave it out and the tool reads the sector from your other inputs and names what it read
competitorsYesCompetitor names, comma-separated. You get one battle card for each competitor named
recent_winsNoWhy customers chose you over competitors: used as your strengths when none are given
your_sectorNoOptional: your company's own industry (not your customers'). When given, it decides the sector notes; when left out, the tool reads it from your words and stays neutral if they are unclear.
your_productYesYour product name and brief description
recent_lossesNoWhy you lost deals to competitors: used as your gaps when none are given
business_modelNoOptional: how you earn revenue, so the advice fits it (saas, services, connectivity, transactions, marketplace, hardware_software or investment). Leave it out and the tool reads it from your other inputs and says how it read it
your_strengthsNoOptional: what you do better, comma-separated. Taken from your wins, in your own words, if not provided
your_weaknessesNoOptional: where competitors beat you, comma-separated. Taken from your losses, in your own words, if not provided
common_objectionsNoSales objections you hear (comma-separated). E.g., 'too expensive, missing X feature, competitor has better Y'
competitor_detailsNoOptional: Any known details about competitors, one per line or separated by semicolons. E.g., 'Competitor A is cheaper; Competitor B targets enterprise'. Each detail goes to the competitor it names

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / industry / description
      Previous value: -"Optional: the sector you sell into, so the answer uses that sector's buyers, measures and objections. Leave it out and the tool reads the sector from your other inputs and names what it read"New value: +"Optional: your own company's sector, so the answer uses the usual buyers, measures and objections for what you sell. Leave it out and the tool reads the sector from your other inputs and names what it read"
  2. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful output behavior: one battle card per competitor, competitor details mapped to the named competitor, each objection answered, and strengths/gaps kept in the user's own words; it lacks failure or limitation details, so not a 5.

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?

The description is a single dense paragraph with the purpose front-loaded and no obvious filler. It could be more readable if split into purpose vs output-mapping sentences, but it is appropriately sized for an 11-parameter tool.

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 complex 11-parameter tool with no output schema, the description explains the input-to-output mapping and what each battle card contains, which is enough to invoke it correctly. It does not fully specify the internal structure of the battle card, so a 5 would be too generous.

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 100%, so the schema already documents all 11 parameters in detail. The description restates several fallback behaviors and the competitor-detail mapping, adding only 'each objection gets its own answer' as a small semantic addition beyond the schema.

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?

State specific evidence: it says it returns one battle card per named competitor built from strengths, weaknesses, competitor details, objections, wins and losses. That is a clear verb and resource, but it does not explicitly distinguish itself from the sibling GTM tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for competitive battle-card preparation, but it gives no explicit when-not guidance and does not name alternatives among siblings such as craft_gtm_analyzer or pmf_scorecard.

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.