Skip to main content
Glama
Sign In
Andru

Andru

by geter-andru
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Weigh the buyer's alternatives

get_competitive_positioning
Read-only

Analyze how your solution stacks up against a named competitor. Discover key differentiators and determine which option aligns best with the buyer's specific role and vertical.

Instructions

Use this when a buyer is weighing another option, or the person asks how they compare with a named alternative. Treats it as diligence for the buyer: where the alternative fits this buyer better, where the person's product does, and questions that help the buyer decide for themselves. Grounded in the account's ICP.

Input Schema

NameRequiredDescriptionDefault
contextNoAdditional context (e.g., "enterprise deal", "competing on price")
verticalNoThe industry the user sells into (e.g., "fintech", "healthcare", "defense"). Infer from conversation context — the user's product description, company name, or the companies they're asking about. If unclear, ask.
targetRoleNoThe buyer role being evaluated (e.g., "CFO", "CTO", "VP Sales"). Infer from context — often explicit in the user's question. If not mentioned, default to the most senior relevant role for their vertical.
competitorNameYesThe alternative the buyer is weighing (a product or company).
competitorFeaturesNoWhat that alternative offers, as you know it.
productDescriptionNoA brief description of what the user's product does and who it's for. Infer this from the conversation if the user has already described their product. If the user hasn't mentioned their product yet, ask them: "What does your product do, and who do you sell to?" before calling this tool.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.4.10
    • changedInput schema / properties / competitorFeatures / description
      Previous value: -"Known competitor features or capabilities"New value: +"What that alternative offers, as you know it."
    • changedInput schema / properties / competitorName / description
      Previous value: -"Competitor company name"New value: +"The alternative the buyer is weighing (a product or company)."
  2. First observedv1.4.0

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds context about the tool's framing ('diligence for the buyer') and grounding in the account's ICP, but does not disclose rate limits, auth needs, or detailed output format beyond the high-level summary.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with the usage trigger, followed by a clear behavioral summary and grounding context. Every sentence contributes directly to understanding when and how to use the 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 read-only analysis tool with no output schema, the description adequately explains what the tool produces ('where the alternative fits this buyer better, where the person's product does, and questions that help the buyer decide'). It omits details like output format or length, but the core value is conveyed.

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%, with detailed per-parameter guidance (e.g., how to infer vertical, targetRole, productDescription). The description adds no additional parameter meaning beyond what the schema already provides, so baseline 3 is appropriate.

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?

The description states a specific scenario and what the tool does: 'Treats it as diligence for the buyer: where the alternative fits this buyer better, where the person's product does, and questions that help the buyer decide for themselves.' This clearly distinguishes it from generic analysis tools, but it does not explicitly contrast with siblings like get_market_signals or get_icp_fit_score.

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?

It gives explicit when-to-use conditions: 'Use this when a buyer is weighing another option, or the person asks how they compare with a named alternative.' No when-not-to-use or alternative tools are named, so it falls short of a 5.

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