Skip to main content
Glama

Shipfound

by co.shipfound.api
OverviewDiscussionsAdmin

Read a boost

boost_results
Read-only

A boost against its stop rule and, with several posts, against each other: each post's click rate, cost per click, cpmUsd (cost per 1,000 impressions), and the visits and signups its tagged link brought; costAlarm when an ad pays over twice the top of the platform's CPM range after $10, with the likely setup causes; taggingNote when the platform shows clicks but few or no visits carry the boost's tags; the verdict (not launched, needs numbers, too early, stop, winner, no clear winner, working, lost after click: people clicked and none signed up). A winner is called only at a 90% chance of being the best, once each post has 1,500 impressions; on signups once there are 5, else on clicks. path: the visits past the click (stayed, reached the signup page, signed up, paid), by phone and desktop, against the site's usual engaged rate; diagnosis: the step that lost people (message, page, device, signup, or holding) and its next move; devicesNote: a split boost's desktop and phone ad groups side by side; retarget: whether enough visits did not sign up to offer the optional retargeting ad. Without id, the latest boost. With history true, instead every boost launched before: its posts' links and words, where it went and its verdict, so a new boost tests something new. Free.

Input Schema

NameRequiredDescriptionDefault
idNo
historyNoEvery boost launched before, instead of one read-out

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / history
      Added value: +{
+  "description": "Every boost launched before, instead of one read-out",
+  "type": "boolean"
+}
  2. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already mark this as a safe read (readOnlyHint=true, destructiveHint=false), and the description adds extensive behavioral detail beyond them: verdict categories, winner thresholds (90% confidence, 1,500 impressions, 5 signups), costAlarm triggers, taggingNote conditions, path stages, diagnosis outcomes, and retargeting logic. No contradictions with annotations.

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

Conciseness3/5

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

The content is information-dense and most clauses earn their place because there is no output schema. But it is delivered as one enormous run-on sentence with semicolons and colons, making it hard to scan. Front-loading is reasonable, yet structure could be substantially improved with separate sentences or bullets.

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?

There is no output schema, so the description carries the full burden of explaining return values—and it does so thoroughly: metrics, verdicts, alarm conditions, path, diagnosis, device notes, retargeting, and history mode. An agent has enough information to call and interpret the tool correctly.

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

Parameters5/5

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

Schema coverage is only 50%, but the description fully compensates. It explains that omitting id returns the latest boost, that history=true returns every prior boost instead, and what history mode returns (links, words, destination, verdict). This gives meaning to both parameters 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?

The description clearly conveys that this tool reads a boost's performance: click rate, CPC, CPM, visits, signups, verdicts, path, diagnosis, and retargeting readiness. It distinguishes the single-boost read from the history mode. However, it opens with an awkward noun fragment ('A boost against its stop rule...') rather than a clean verb+resource statement, and does not explicitly name sibling tools like boost_record or boost_plan.

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 clear usage context for both modes: 'Without id, the latest boost' and 'With history true, instead every boost launched before.' The purpose of history mode is explained ('so a new boost tests something new'). It stops short of naming alternatives or explicit when-not-to-use conditions against siblings such as boost_record.

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

All Shipfound toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources