Skip to main content
Glama

company_intelligence_review

Build a weekly intelligence review by combining persisted business metrics with sealed documents, verifying freshness, and ranking actions by severity and financial impact.

Instructions

Build the sealed weekly intelligence review: every product and services document the bundle's plans allow is built now from the persisted chains (margin, portfolio, price probes, the contribution bridge when previous_window_start is given, customer profitability, services margin, rate card), any supplied sealed documents are added (skills match, sourcing, inventory, capacity, job quotes), each is bound by digest and checked for freshness, and the actions are ranked by severity and the money at stake with blind spots named (payload: review_ref, optionally documents, window_start, window_end, previous_window_start, profiles, max_age_days).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nowNo
engineNo
operationNobuild
entity_refNo
project_idYes
bundle_jsonYes
payload_jsonNo{}

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.2

TDQS

C2.7/5.0
Behavior3/5

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

With no annotations, the description carries the burden. It discloses several behaviors: documents are bound by digest, checked for freshness, actions ranked by severity and money at stake, blind spots named. However, it does not mention side effects (e.g., whether it persists anything, overwrites previous reviews) or permission/rate-limit implications, leaving part of the behavioral profile undisclosed.

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 a single dense run-on sentence with no paragraph breaks or list structure. While information-dense, it is hard to parse and violates conciseness: it buries the payload specification in a wall of text instead of front-loading key semantics.

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

Completeness2/5

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

Given the tool's complexity (7 params, composite behavior) and 0% schema coverage, the description is incomplete. It does not explain the meaning of project_id/bundle_json, define 'sealed', describe how sealed documents are supplied, or clarify the output beyond what an output schema might provide. An agent would struggle to invoke this correctly without additional context.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It explains the payload fields (review_ref, documents, window_start, window_end, previous_window_start, profiles, max_age_days) but completely ignores the required top-level parameters project_id and bundle_json, as well as now, engine, operation, and entity_ref. An agent cannot infer how to populate the required fields.

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 verb and resource ('Build the sealed weekly intelligence review') and enumerates the exact components included (margin, portfolio, price probes, etc.), making the tool's purpose clear. It doesn't explicitly contrast with siblings like company_product_margin or company_services_margin, but the composite nature is evident.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives such as company_product_margin or company_services_margin. The description implies a weekly review workflow but does not state prerequisites, exclusions, or how it differs from the individual company_* tools it aggregates.

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