Skip to main content
Glama

StackFast FractWin Expert Brain

GrowthOS Opportunity Scout Packet

growthos_opportunity_scout_packet
Read-onlyIdempotent

Build an Opportunity Scout packet for customer, talent, contract, or capital opportunities using the existing gate-first policy layer and no new persistence table.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
opportunityYesOpportunity input. opportunity_type must be one of the registered Opportunity Scout types.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
toolYes
public_nameNo
no_autonomous_outboundNo
review_required_before_sendNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • removedOutput schema / description
      Removed value: -"Structured JSON result envelope. Tool-specific fields vary by product surface; outputs are governed, audit-safe, and omit secrets."
    • addedOutput schema / properties
      Added value: +{
      +  "no_autonomous_outbound": {
      +    "type": "boolean"
      +  },
      +  "ok": {
      +    "type": "boolean"
      +  },
      +  "public_name": {
      +    "type": "string"
      +  },
      +  "review_required_before_send": {
      +    "type": "boolean"
      +  },
      +  "tool": {
      +    "type": "string"
      +  }
      +}
    • addedOutput schema / required
      Added value: +[
      +  "ok",
      +  "tool"
      +]
  2. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds meaningful behavioral context beyond those: it states the operation uses the 'existing gate-first policy layer' and creates 'no new persistence table,' which clarifies that this is a non-persistent, policy-governed packet build. No contradiction 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.

Conciseness5/5

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

One sentence that front-loads the action and resource, immediately lists scope categories, and appends constraints ('gate-first policy layer' and 'no new persistence table'). There is no redundant or filler content.

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?

Given the simple one-parameter schema, the rich annotations, and the presence of an output schema, the description is complete. It covers what is being built, for which opportunity types, and the key behavioral constraints, leaving no critical invocation ambiguity.

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?

Schema coverage is 100% for the single parameter, so the baseline is 3. The description adds value by listing potential opportunity categories (customer, talent, contract, capital), giving the agent hints about what the nested 'opportunity_type' field might contain beyond the schema's generic 'registered Opportunity Scout types' phrasing.

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 states a specific verb ('Build'), a specific resource ('Opportunity Scout packet'), and enumerates the covered opportunity categories (customer, talent, contract, or capital). This clearly communicates the tool's function and distinguishes it from vague or generic packet tools in the sibling list.

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?

The description gives clear context for when to use the tool: when an Opportunity Scout packet is needed for one of the named opportunity categories. It does not explicitly name alternatives or exclusions, but the scope is specific enough that an agent can infer appropriate use.

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.

Resources