Skip to main content
Glama

VarynForge

by com.varynforge

Get pitch report payload

get_pitch_report_payload
Read-only

Assemble the client-ready pitch report payload for a completed research run — niche + solution profile, competitor landscape, ranked opportunity map holding GAPS ONLY (0-100 normalized; demand sized as volumeBucket buckets, no search-volume numbers by design; each entry carries overlapStatus net_new|partial plus siteOverlap — covered-keyword share + closest owned pages), coveredOpportunities as a separate defend-and-refresh list (topics the site already covers — never pitch these as new work), and a derived 90-day content sequence sized to the project posting cadence (postsPerWeek, up to 12 weeks; planned articles first, then gap topics marked type: topic — topics to develop, not article titles; covered clusters never enter the sequence; entries may carry advisory notes — near-duplicates, already-published near-matches, working titles needing a rewrite — keep the notes visible when rendering). assetProfile reports when the profile facts were last synced; when assetProfile.syncedBeforeRun is true, offer the operator the choice between resync_asset_profile first and rendering with the profile as-is, and always render the "Asset profile last synced " stamp. renderGuide carries the full report structure with an explicit branding slot: render it in the operator’s own template (Docs, Slides, Notion, or PDF) under the operator’s name. Included with every run, no extra cost. Pass the runId from get_research_status; a run that is not completed returns { runStatus, report: null }.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
runIdYes
contextYesOne sentence: what is the operator trying to achieve right now? Describe their goal, not this tool's purpose.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed2 schema fields changed
    • addedInput schema / properties / context
      Added value: +{
+  "description": "One sentence: what is the operator trying to achieve right now? Describe their goal, not this tool's purpose.",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "runId"
-]New value: +[
+  "runId",
+  "context"
+]
  2. Added

TDQS

A4.4/5.0
Behavior5/5

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

The readOnlyHint annotation already marks this as safe, and the description adds substantial non-obvious behavior: the opportunity map holds gaps only, no search-volume numbers by design, covered opportunities must never be pitched as new work, covered clusters never enter the 90-day sequence, incomplete runs return null report, and the renderGuide requires operator branding. This goes far beyond the structured annotations.

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

Conciseness2/5

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

The description is very long and written as a dense single paragraph with many embedded parentheticals. It front-loads the purpose but buries the key invocation guidance toward the end, and includes less essential details like 'Included with every run, no extra cost.' The content is valuable but would benefit from structured bullets and tighter editing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only tool with no output schema, the description is unusually complete. It defines the payload structure, conditional behaviors, the null result for incomplete runs, the resync choice, rendering expectations, and the runId source. An agent has enough context to select and invoke the tool correctly without additional lookups.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema describes the context parameter well, and the description adds the critical runId semantics: it must come from get_research_status and must reference a completed research run. Since only half the parameters are schema-documented, the description partially compensates by clarifying the more operationally important parameter.

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 description clearly states the tool assembles a client-ready pitch report payload for a completed research run and enumerates the major payload components: opportunity map, coveredOpportunities, 90-day content sequence, assetProfile, and renderGuide. It is unambiguous and distinct from sibling getters because it defines a unique output contract and even names get_research_status as the source of the runId.

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 context: use with a completed research run and pass the runId from get_research_status. It warns that an incomplete run returns { runStatus, report: null }, and it provides a conditional alternative by offering resync_asset_profile when assetProfile.syncedBeforeRun is true. It does not enumerate all sibling exclusions, but the usage context is clear.

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

All VarynForge toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0
Disambiguation4/5

Most tools target a distinct resource and action, and the descriptions carefully cross-reference close alternatives (e.g., add_article_suggestion vs create_article_suggestion_with_input vs accept_idea). A few brief/read variants like get_article_brief, get_write_handoff, and download_brief_markdown could still be confused despite helpful explanations, so the set is not perfectly unambiguous.

Naming Consistency5/5

Tool names follow a highly consistent verb_noun snake_case pattern throughout: get_*, list_*, create_*, update_*, set_*, add_*, delete_*, start_*, expand_*, etc. Even the less common names like lint_draft and remap_asset are still clear verb_noun constructions.

Tool Count1/5

At 57 tools, this far exceeds the 50+ extreme threshold for a single MCP server. Even for a broad content workflow, the surface is overwhelming and would benefit from consolidation or splitting into focused servers.

Completeness4/5

The tool set covers the full content lifecycle: project setup, research runs, opportunity clustering, suggestion creation, brief generation, drafting, linting, publishing, reporting, and account management. Minor gaps exist—destinations and projects cannot be deleted via MCP, and there is no direct update for article suggestion metadata—but these are workable via the web UI or existing tools.

Resources