How strong is this startup or deal on paper? Scores an opportunity across seven pillars weighted by stage (pre-seed to series B+), applies red flags, and returns a 0 to 10 score with pass, investigate or fail. Deterministic: the same input always gives the same score. A screening aid, not investment advice. Price: $0.01 USDC on Base via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| stage | No | ||
| pillars | No | ||
| redFlagIndices | No | ||
| opportunityName | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover readOnlyHint and openWorldHint; the description goes well beyond by disclosing determinism ('same input always gives the same score'), the advisory limitation, and the exact cost and payment rail ($0.01 USDC on Base via x402). Cost and determinism are exactly the behavioral facts an agent needs before calling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with the core question and then the mechanics, verdict, determinism, disclaimer and price. The rhetorical opening line is the only slight indulgence; everything after it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does explain the return conceptually (0-10 plus a three-way verdict) and flags the payment requirement. The remaining gap is that it doesn't say whether a pillar-level breakdown comes back, which an agent reporting results would want.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the whole burden. It partially compensates by explaining that pillars are scored across seven dimensions and that stage weighting and red flags drive the result, which gives the arrays meaning, but it never says what an individual pillar entry looks like or what the 1-15 redFlagIndices refer to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('scores an opportunity'), names the mechanism (seven pillars weighted by stage), and specifies the output (0-10 score with pass/investigate/fail). An agent can tell this apart from the base_* and audit_* siblings immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It frames the tool's role ('a screening aid, not investment advice') and the applicable range (pre-seed to Series B+), which implies when it fits, but never states when to use it versus alternatives or what disqualifies an opportunity from being scored here.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.