Loading ToolBench
MCP server for Primr company research and intelligence platform. Provides tools for company research, strategy generation, skill pack creation, job management, and agentic capabilities including roadmap queries and hypothesis management.
The Primr MCP server defines 10 tools with generally clear purposes and reasonable schemas. Most tools have descriptions (9/10 present), but several lack depth or LLM-optimized guidance. Parameter descriptions are present across most tools, but some are generic or incomplete. Tool naming follows verb_noun convention consistently. A key strength is cost-gating and approval workflows for high-stakes operations. Major weaknesses: (1) several parameters lack detailed format/constraint documentation, (2) output schemas are not explicitly documented, (3) error handling strategies are not surfaced in descriptions, (4) some tools have interdependencies not clearly stated in descriptions.
Cancel an owned job
Estimate cost and time for a research run without executing. Call this before any cost-incurring research run.
Estimate cost and time to produce a skill pack for a company. Call this BEFORE generate_skill_pack to satisfy the standard estimate-first gate. Cost scales with the requested roster, skill count, and refinement cap.
Estimate cost and time for a strategy document without executing. Call this before any cost-incurring strategy generation.
Generate a QA-refined Agent Skills pack for a company. Produces both a Claude/Cursor/VS Code-ready unpacked tree AND a Microsoft 365 Copilot Cowork sideload .zip from one byte-identical set of SKILL.md files. Internal QA pipeline: role discovery, best-practices grounding, parallel authoring, deterministic validation, per-skill refinement (capped), pack-level coherence pass. Synchronous (~30-120s).
Output schemas not documented. Tools like research_company (returns job_id), estimate_run (returns cost estimate, time estimate), and generate_skill_pack (returns file paths and metadata) do not have explicit response schema documentation. LLMs cannot reliably infer what fields to extract or how to chain to downstream tools.
Parameter format and constraint documentation inconsistent. estimate_run's 'mode' enum is clear, but 'max_estimated_cost_usd' lacks guidance on precision (cents? dollars?). generate_skill_pack's 'formats' enum (claude|cowork|both) is clear, but 'destination' lacks path format spec. Missing format guidance forces LLMs to guess or retry on validation failure.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 32 | - | v1 |
Generate strategy document from an existing report AFTER the fact. Only needed when adding a strategy to a previously completed research run. For new research, use research_company with platform instead; strategy is included automatically.
Retrieve hypotheses for a company from research memory
Query the roadmap for version status, blockers, or features
Initiate the supervised company research pipeline and return a job_id after the worker is ready. Full and premium include an agnostic AI Strategy by default unless no_ai_strategy is true. This incurs real API cost and should only be called after the user approves an estimate from estimate_run.
Save or update a hypothesis in research memory
Interdependencies not surfaced in descriptions. research_company can auto-generate strategy if platform is set, but generate_strategy is for post-hoc strategy. This distinction is buried in long descriptions. estimate_run should be called before research_company (cost-gating pattern), but the dependency is implicit in the description text rather than explicit in a 'call this first' guideline.
query_roadmap description is vague ('Query the roadmap for version status, blockers, or features'). What is the output format? Does it return markdown, JSON, or free text? When would an LLM call this vs. inspect docs directly? No guidance on valid query patterns or expected response structure.
Error handling strategies not documented. Tools like research_company incur real API cost. What happens if estimation fails? Can the LLM retry? Should it ask the user? No recovery guidance in descriptions. Similarly, generate_skill_pack is synchronous (~30-120s) but no timeout or failure mode is documented.
Approval token semantics unclear. research_company and generate_strategy both accept 'approval_token' but no description explains how to obtain it, what it validates, or when it is required. This forces LLMs to guess or fail with a cryptic error.
Platform parameter aliases (azure=microsoft, aws=amazon, gcp=google, private=nvidia) are documented inline but not enforced or validated clearly. estimate_strategy accepts 'ms' as alias but estimate_run does not. Inconsistency forces LLM to track multiple valid values per tool.
Tool risk classifications (READ_ONLY, WRITE, REVERSIBLE) are present in tool_authz.py but not surfaced in tool definitions or descriptions. LLMs cannot see these; they should be annotations or explicit parameter guards.