Run local, deterministic idea-audit arithmetic: score ideas, compute verdicts, and inspect every number — no accounts, network, or model calls.
Core verdict: compute_dealbreakers_v2 returns GO/KILL with stage-aware weights, confidence weighting, and risk-asymmetric thresholds; optional observer adds a crossed verdict and 5-archetype matrix.
Explore counterfactuals: compute_crossed_matrix compares substrate vs solo/cofounded/domain-expert/serial founder archetypes.
Turn verdicts into action: derive_kill_criteria builds falsifiable kill rules from unit economics + dealbreaker results.
Assess market shape: compute_barrier, compute_multi_source_tam, compute_search_velocity / _v2, compute_social_pain.
Read money signals: validate_unit_economics, compute_monetization, compute_budget_proof, compute_ppc_spend_signal.
Track momentum/signals: compute_funding_momentum, compute_hiring_demand, compute_x_signal, compute_build_complexity.
Compose scores: compute_lrs_composite / _v2, compute_urgency_composite, compute_collection_scores.
Runs over stdio as an MCP server; identical to hosted server for these tools, but deliberately refuses persistence (auditId) and makes no external data calls.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ideaudit-tools Run a dealbreaker audit on my startup idea and give me the verdict."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
The deterministic scoring behind ideaudit, as a local MCP server. No account, no key, no network, no model calls — just the arithmetic.
claude mcp add ideaudit-tools -- npx -y @inite/ideaudit-toolsListed in the MCP registry as studio.inite/ideaudit-tools, which carries
both ways in: this package over stdio, and the hosted server over HTTP.
Installing straight from this repository — npx -y github:inite-ai/ideaudit-mcp
— also works and runs the same code.
The product's claim is that it is an audit allowed to say no. A verdict
nobody can inspect is a verdict nobody has to believe, so the part that
produces the number is open — including the number that says no. You can read
how three lens scores become KILL, disagree with the thresholds, and argue
about the arithmetic rather than about our word.
It is also the honest shape of the system. The server makes zero model calls; judgement lives in the skills, determinism lives in the tools. These are the tools.
Related MCP server: NUVC MCP Server
Twenty tools, every one a pure function of its input:
The verdict |
|
Composite scoring |
|
Market shape |
|
Money |
|
Signals |
|
compute_dealbreakers_v2 is the one that decides. Stage-aware weights,
confidence-weighted lens scores, and a deliberately risk-asymmetric verdict:
GO needs a score ≥ 80 and zero red flags and average confidence ≥ 0.6,
while the KILL gate is observer-invariant — a founder profile shifts every
threshold above the gate, and none of them below it. You cannot buy a better
answer by describing yourself more favourably. There is a test that says so.
Same input, same output as the hosted server — because it is the same specification object, imported rather than reimplemented. A test asserts that identity rather than comparing two copies, so the two cannot drift.
Be told where the numbers are rather than hunt for them:
src/specs/*.ts — one file per tool: what it accepts, what it means,
what it returns. compute-dealbreakers-v2.ts is the verdict.
src/server.ts — the whole server, including what it refuses.
src/__tests__/parity.test.ts — the claims above, as assertions. The
observer-invariant KILL gate is checked against all five archetypes.
dist/bundle.js — the arithmetic, un-minified. computeBarrier is a
dozen lines and every constant is visible: 0.6 off the score per direct
competitor, 0.2 per adjacent, six points of range spent on SERP noise, and
labels at 18 / 12 / 6. Disagree with those numbers, not with our word.
That last one is a build artefact and reads like one — the commented source of the maths lives in the monorepo this repository is mirrored from, and is not here. If you want the reasoning behind a threshold rather than the threshold itself, open an issue and ask; that is a cheaper conversation than either of us pretending.
Not withheld to make a point — these genuinely need somewhere to keep things and someone to pay for them:
Persistence. Saving an audit, finalising it, reading it back, comparing two of them, the dashboard. A verdict that exists only in a chat transcript is one nobody can re-open or defend later.
Data. SERP, keyword volume, funding rounds, hiring signals, social mentions. Those are metered third-party APIs.
The knowledge graph. Entities, evidence, contradictions across audits.
That boundary is enforced rather than documented. The hosted
compute_dealbreakers_v2 takes an auditId; this one refuses it, by name,
instead of letting zod strip it silently and handing you a correct verdict
plus the false belief that it had been written down.
$ compute_dealbreakers_v2 {"auditId": "…", …}
{ "error": "unknown_arguments", "unknown": ["auditId"],
"message": "This server computes; it stores nothing. …" }claude mcp add ideaudit --transport http https://api.inite.studio/mcp \
--scope user --header "Authorization: Bearer $IDEAUDIT_API_KEY"It serves these twenty tools and everything above them. Sign up at
inite.studio; --scope user matters, or the
registration is bound to one directory.
They compose. Register the local server for the arithmetic and the hosted one for everything else; tool names do not collide because the local set is a strict subset served under the same names, so whichever you register wins for those twenty and the rest resolve to the platform.
If you only want to check our maths against your own numbers, the local server alone is enough and always will be.
This repository is a projection. It is rebuilt and force-pushed from the monorepo that develops it every time the package changes, which means a pull request opened here would be overwritten by the next sync — through no fault of yours, and with no notification. Saying so is cheaper than letting someone find out by losing an afternoon.
Issues are the right channel and they are read: a threshold you think is wrong, a number you cannot reproduce, a tool that accepts something it should refuse. Bring the input you used — every tool here is deterministic, so a disagreement about an answer is always settleable.
Apache-2.0. See LICENSE.
Compute barrier_score (0-24) + label (PRISTINE/OPEN/COMPETITIVE/CROWDED) from competitor counts + SERP noise fraction.
| Name | Required | Description | Default |
|---|---|---|---|
| serpNoise | No | ||
| directCompetitorCount | Yes | ||
| adjacentCompetitorCount | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the output scale and label set, but does not explain how the inputs map to the score (e.g., thresholds, direction of the score, or edge cases). This is acceptable for a pure computation tool but not fully transparent.
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?
One sentence with no filler; it front-loads the output and lists the input variables compactly. Every phrase carries meaning.
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?
For a simple computation tool with no output schema, the description states both the return value (score range and label set) and the input basis, which is enough to invoke it. It omits the scoring logic, but that is not necessary for correct invocation.
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 description coverage is 0%, so the description must compensate. It conceptually covers all three inputs ('competitor counts' includes direct and adjacent, plus 'SERP noise fraction'), but it does not explain the direct/adjacent distinction or default behavior; the schema's constraints must fill that gap.
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?
The description uses a specific verb ('Compute') and names the exact resource and output shape (barrier_score 0-24 plus a label category). It also identifies the inputs, so the tool's function is clear even though it does not explicitly compare itself to sibling compute_* tools.
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?
Usage is only implied: this is the tool to use when you need a barrier score from competitor counts and SERP noise. There is no explicit when-to-use/when-not-to-use guidance or mention of alternative sibling scoring tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute budget_proof_score (0-10) + label (STRONG/CONFIRMED/WEAK/ABSENT) + purchase_intent_pct from pricing hits + review-site hits + intent mentions.
| Name | Required | Description | Default |
|---|---|---|---|
| hasNamedPricing | No | ||
| pricingHitsCount | Yes | ||
| reviewSiteHitsCount | No | ||
| purchaseIntentMentions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not state whether the tool is a pure calculation, whether it makes external calls, what happens with missing optional inputs, or any side effects. The phrasing 'from pricing hits + review-site hits + intent mentions' is ambiguous—it could imply data fetching rather than using the provided count parameters.
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?
The description is a single compact sentence with no filler, front-loading outputs before inputs. It could be slightly better structured with explicit separation of inputs and outputs, but it remains efficient and scannable.
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?
For a simple four-parameter calculator, the description is minimally viable: it lists the outputs. However, with no output schema, it omits the return structure, label thresholds, and behavior when optional parameters are absent. An agent would need to guess how the label is derived from the inputs.
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 description coverage is 0%, so the description must explain parameter roles. It gives a high-level mapping for three parameters (pricing hits, review-site hits, intent mentions) but completely omits hasNamedPricing and does not explain how any parameter influences the score, label, or percentage.
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?
The description names a specific resource (budget_proof_score with 0-10 range), explicit outputs (label categories and purchase_intent_pct), and concrete input ingredients (pricing hits, review-site hits, intent mentions). This clearly distinguishes it from the many sibling compute_* tools, which address different signals.
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?
There is no guidance on when to invoke this tool, no context about the decision it supports, and no comparison to alternatives like compute_monetization or compute_urgency_composite. The intended use is only implied by the tool name and outputs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute build_complexity_penalty (0-10, higher = worse) + per-factor breakdown. Hard tags: ml/realtime/blockchain/hardware/compliance/custom-ai/regulated/on-device-ai/iot.
| Name | Required | Description | Default |
|---|---|---|---|
| externalApisCount | Yes | ||
| integrationsCount | No | ||
| stackComplexityTags | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does communicate the output nature (scale, direction, breakdown) and lists the hard tags, which are likely behavioral triggers. However, it does not explicitly state whether the operation is read-only, what a hard tag actually does to the score, or edge-case behavior.
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?
Two sentences with no filler. The first sentence front-loads the output and scale; the second gives a compact, relevant list of hard tags. Every word 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?
Given 0% schema coverage, no annotations, and no output schema, the description is insufficient for confident invocation. It omits the semantics of two parameters, does not explain how hard tags are applied, and provides no routing context. An agent would need additional reasoning to call this tool correctly.
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 description coverage is 0%, so the description must compensate. It adds meaning only for stackComplexityTags by listing the hard tags, but externalApisCount and integrationsCount are completely undocumented in both the schema and the description. An agent cannot know how those numeric parameters affect the penalty.
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?
The description explicitly states the tool computes a build_complexity_penalty with a 0-10 scale, higher = worse, plus a per-factor breakdown. This is a specific verb+resource+output and leaves no doubt about the tool's core function. It does not explicitly differentiate from sibling compute_* tools, but the metric and hard-tag list make the purpose clear.
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?
No guidance is provided for when to use this tool versus any of the many compute_* siblings. There is no mention of alternatives, conditions, or context in which build complexity should be computed rather than other metrics. The agent is left to infer routing solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute 12 deterministic collection scores (0-100) + badges + death reason for an enriched idea. Pure math. No external calls.
| Name | Required | Description | Default |
|---|---|---|---|
| analysisId | Yes | ||
| enrichedData | Yes | EnrichedData with canonical_idea signals. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses deterministic behavior, pure math, and no external calls, which are meaningful behavioral traits beyond the schema. It could add details about invalid inputs or exact return shape, but the core side-effect and reliability profile is clear.
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?
The description is two tight sentences, front-loads the concrete outputs, and includes only high-value behavioral constraints. There is no filler or unnecessary repetition.
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?
The description names the outputs and score range, which is useful given there is no output schema. However, it does not explain the structure of badges/death reason, the role of analysisId, or when this aggregate computation should be used relative to the many sibling compute tools. It is adequate but not complete.
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?
enrichedData is partially documented in the schema and echoed by 'enriched idea' in the description. analysisId has no description in either the schema or the tool description, though its purpose as an identifier is inferable. With 50% schema coverage, the description adds some but not full parameter clarity.
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?
The description states a specific verb and resource: it computes 12 collection scores, badges, and a death reason for an enriched idea. It also specifies the score range (0-100), which distinguishes this aggregate scoring tool from sibling tools that compute individual signals like compute_barrier or compute_funding_momentum.
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?
The description gives context that it applies to an enriched idea and is pure math, but it does not say when to choose this tool over the many sibling compute_* tools. No exclusions or alternative routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crossed-product audit explorer. Same input as compute_dealbreakers_v2 — returns substrate verdict (no-observer baseline) + crossed verdict (when observer supplied) + a 5-row matrix of {solo, cofounded_technical, cofounded_business, domain_expert, serial} archetype verdicts. Never persists; meant for the dashboard "view as [archetype]" dropdown and for previewing a verdict before committing to it.
| Name | Required | Description | Default |
|---|---|---|---|
| stage | Yes | ||
| sector | No | ||
| observer | No | Founder profile that crosses with the substrate idea to produce an observer-relative verdict. When omitted, only the substrate verdict is returned. | |
| lensScores | Yes | ||
| stageProbabilities | No | ||
| hasMajorContradiction | No | ||
| unresolvedContradictions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool never persists, that the substrate verdict is returned without an observer, and that the crossed verdict appears only when an observer is supplied. This gives a good sense of side effects and output variability, though it does not detail error behavior or side-effect guarantees beyond persistence.
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?
The description is compact and information-dense, with no filler. It front-loads the core concept, then uses an em-dash list for the return components and a final sentence for usage context. The only minor issue is the slightly jargon-heavy opener 'Crossed-product audit explorer,' but it is followed by concrete clarification.
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?
Given the tool's complexity — seven parameters, nested objects, no output schema, and twenty siblings — the description covers the core purpose and return structure well. However, it leaves parameter semantics largely to inference, does not explain the relationship to compute_dealbreakers_v2 beyond 'same input,' and provides no detail about the structure of the verdict objects or the matrix rows. It is adequate but not fully complete for autonomous selection and invocation.
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 description coverage is only 14%, so the description needed to compensate by explaining key parameters. It does add meaning for the observer object by listing the five archetype values and tying them to the output matrix, but it does not clarify stage, lensScores, stageProbabilities, or the optional boolean/integer fields. Most parameters remain underspecified from an agent's point of view.
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?
The description clearly identifies the tool as a crossed-product audit explorer that takes the same input as compute_dealbreakers_v2 and produces a substrate verdict, a crossed verdict, and a five-row archetype matrix. It distinguishes itself from compute_dealbreakers_v2 by explicitly naming that sibling and describing the additional archetype-oriented output.
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?
The description states when to use the tool: for the dashboard 'view as [archetype]' dropdown and for previewing a verdict before committing. It also names compute_dealbreakers_v2 as the related alternative and explains how the observer parameter changes behavior. It lacks explicit 'do not use when...' exclusion criteria, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Methodology v2 dealbreakers — stage-aware weights + confidence-weighted lens scoring + risk-asymmetric verdict (GO requires score≥80 AND zero red flags AND avg confidence≥0.6). Optional observer triggers the crossed-product pipeline: substrate verdict (no-observer baseline) PLUS crossed verdict (observer-perturbed weights, risk-tolerance shifted thresholds) PLUS 5-row archetype matrix. The KILL gate (≥2 blockers / score<50) is observer-invariant — fatal stays fatal.
| Name | Required | Description | Default |
|---|---|---|---|
| stage | Yes | ||
| sector | No | ||
| observer | No | Founder profile that crosses with the substrate idea to produce an observer-relative verdict. When omitted, only the substrate verdict is returned. | |
| lensScores | Yes | ||
| stageProbabilities | No | ||
| hasMajorContradiction | No | ||
| unresolvedContradictions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden and discloses substantial behavioral detail: exact GO conditions, the KILL gate, and the observer-invariance of fatal verdicts. It does not discuss side effects or error behavior, but for a compute-style tool the disclosed thresholds and branching behavior are the most important traits.
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?
The description is appropriately sized and front-loads the most decision-relevant information: the GO/KILL thresholds and the observer pipeline. The middle sentence is a dense run-on list, but every clause contributes meaning and there is no filler.
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?
The core algorithm and observer branch are well covered, but this is a complex 7-parameter tool with nested objects, low schema description coverage, and no output schema. The description does not explain the returned verdict structure or the roles of several optional parameters, so an agent cannot fully anticipate behavior for all valid inputs.
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?
The description adds real meaning to lensScores and stage by explaining how scores, red flags, confidence, and stage-aware weights drive the verdict, and it clarifies how the observer object perturbs weights and thresholds. However, schema description coverage is only 14%, and the description says nothing about sector, stageProbabilities, hasMajorContradiction, or unresolvedContradictions, leaving their roles to inference.
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?
The description clearly identifies the tool as a methodology-v2 dealbreaker computation and states its core mechanics: stage-aware weights, confidence-weighted lens scoring, and risk-asymmetric verdict logic. It also distinguishes the tool from generic compute siblings by specifying GO/KILL thresholds and the observer-triggered crossed-product pipeline.
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?
The description gives parameter-level usage guidance: omit observer for the substrate baseline, include it for the crossed verdict and archetype matrix. However, it never explicitly says when to prefer this tool over sibling alternatives like compute_crossed_matrix or derive_kill_criteria, so the usage guidance remains mostly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute funding_momentum_score (0-10) + badge (HOT/WARM/COOL/COLD) from tier-weighted funding-article hit counts.
| Name | Required | Description | Default |
|---|---|---|---|
| hitsByTier | Yes | ||
| recent30dHits | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, yet it only discloses the output range and badge categories. It does not reveal how tier weighting works, what threshold produces each badge, how zeros are handled, or the role of the optional recent30dHits parameter, leaving the computation opaque.
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?
The description is a single, front-loaded sentence that names outputs before inputs and contains no filler. It is efficient, though it may be too brief to carry the behavioral and parameter information the agent needs.
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?
This tool has nested inputs, an optional parameter, no output schema, and no annotations. The description does not explain how to populate hitsByTier, what recent30dHits influences, or where badge boundaries lie, making it incomplete for confident invocation in varied scenarios.
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 description coverage is 0%, so the description must compensate by explaining parameters, but it only gestures at 'tier-weighted funding-article hit counts.' It never describes recent30dHits or the distinct tier_1, regional, vertical, and presswire keys, so an agent gets little help understanding what values to pass or how they combine.
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?
The description opens with a direct compute verb and names the exact outputs: funding_momentum_score and a badge. It clearly identifies the tool's topic and differentiates it from most compute_* siblings, though it does not explicitly contrast with any specific alternative.
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?
The description implies this tool is used when funding-momentum scoring from tier-weighted article hit counts is needed. However, it provides no explicit when-to-use conditions, exclusions, or alternatives among the many similar compute_* sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute hiring_demand_score (0-10) from priority-weighted ATS site hit counts (use registries/hiring-sources for priorities).
| Name | Required | Description | Default |
|---|---|---|---|
| sites | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It does not mention side effects, permissions, or data requirements. While it is likely a pure computation, the lack of explicit disclosure limits transparency.
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?
The description is a single, well-structured sentence that conveys the core functionality without unnecessary detail. It is concise and front-loaded.
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?
The description lacks details about the computation formula, output interpretation, edge cases, and dependencies. The hint about registries is vague, and the absence of an output schema leaves the user uncertain about what the score represents.
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?
The description adds meaning by explaining that priority is a weight and that priorities should come from registries/hiring-sources. It does not clarify the semantics of 'domain' or 'hits', but partially enhances the schema.
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?
The description clearly states the tool computes a hiring_demand_score from priority-weighted ATS hit counts, and specifies the output range (0-10). It does not explicitly contrast with sibling tools, but the purpose is unambiguous given the name and description.
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?
There is no guidance on when to use this tool versus alternatives like compute_search_velocity or compute_urgency_composite. The hint about using registries/hiring-sources for priorities is a data-sourcing note, not a usage condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compose lrs_final_100 (0-100) + label (WEAK/EMERGING/GOOD/STRONG/ELITE) + leaderboard_eligible flag + sub-percent breakdown. Weights: sv 0.25, sp 0.30, barrier 0.25, monetization 0.20.
| Name | Required | Description | Default |
|---|---|---|---|
| barrierScore | Yes | ||
| socialPainScore | Yes | ||
| monetizationScore | Yes | ||
| searchVelocityScore | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses the weighting scheme and the output components (final score, label, eligibility flag, sub-percent breakdown), which is useful. However, it omits how labels map to score ranges, how leaderboard_eligible is determined, and whether the operation is a pure computation or has side effects.
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?
The description is compact, front-loads the output components, and then gives the exact weighting formula in a single additional sentence. Every phrase earns its place and there is no filler.
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?
For a four-parameter computation with no annotations and no output schema, the description names the output components and the weights, which is reasonably informative. Still, it leaves significant gaps: label thresholds, leaderboard_eligible logic, the exact nature of the sub-percent breakdown, and any distinction from the v2 sibling tool.
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 description coverage is 0%, so the description must compensate. It maps all four parameters to weights (sv, sp, barrier, monetization) and clarifies their role in the composite calculation. It does not deeply explain the semantic meaning of each sub-score, but the parameter names and the weighting formula provide enough added meaning beyond the raw schema.
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?
The description clearly states the tool's function: composing a composite LRS score from four sub-scores, with a weighted formula and specific output components. It distinguishes itself from the individual compute_* sibling tools by mentioning the inputs, but it does not differentiate itself from the closely related compute_lrs_composite_v2 sibling.
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?
The description gives no guidance on when to use this tool versus compute_lrs_composite_v2 or the individual score calculators. The mention of weights and sub-scores implies the sub-scores should be computed first, but no conditions, exclusions, or alternatives are explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
LRS composite v2 — 6 components (SV, Pain, Barrier, Monet, X-Signal, Budget-Proof). Default Python weights 0.18/0.22/0.18/0.14/0.18/0.10 sum=1.0. Returns BOTH weighted score and equal-weight baseline (per OECD Handbook + Greco 2018 — equal-weight is defensible default when no outcome calibration exists). buildComplexityPenalty 0-10 subtracted from score. sectorProfile (ai_native/creator/crypto) opt-in reshuffles SV→0.16, X→0.20. Labels: THE_ROAR (≥80) / PROMISING (≥60) / EXPERIMENTAL (≥40) / WEAK_SIGNAL (<40).
| Name | Required | Description | Default |
|---|---|---|---|
| barrierScore | Yes | ||
| xSignalScore | Yes | ||
| sectorProfile | No | Opt-in sector weight override. Default uses Python canonical weights. | |
| socialPainScore | Yes | ||
| budgetProofScore | Yes | ||
| monetizationScore | Yes | ||
| searchVelocityScore | Yes | ||
| buildComplexityPenalty | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral disclosure burden. It discloses the default weights, the sum of weights, the equal-weight baseline rationale, the buildComplexityPenalty subtraction, the sectorProfile behavior, and the label thresholds. This is unusually transparent about the scoring behavior.
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?
The description is compact and information-dense, with the core purpose stated first, followed by weights, output behavior, penalty, sector override, and labels. Every sentence adds value and there is no redundant filler.
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?
The description covers the algorithm well but leaves gaps for a complex 8-parameter tool with no output schema: it says 'returns BOTH weighted score and equal-weight baseline' but does not specify the return shape or value ranges, and it does not clarify how this v2 differs from the v1 sibling. The label thresholds imply a 0-100 scale but that is never explicitly stated.
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 description coverage is only 13%, so the description must compensate, and it partially does: it maps the six component abbreviations to the scores, states the default weights, and explains buildComplexityPenalty and sectorProfile roles. However, it does not explain what each underlying score measures, the full sector weight reshuffle for all components, or how the penalty interacts with the final label thresholds.
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?
The description clearly identifies the resource as 'LRS composite v2', lists its six score components, and states that it produces both a weighted composite and an equal-weight baseline. It is specific about the compute behavior, but it does not explicitly contrast itself with the sibling compute_lrs_composite (v1), so a route-taking agent would have to infer the difference from the version and weight details.
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?
No guidance is given about when to use this tool versus the alternative compute_lrs_composite or the individual component scorers such as compute_search_velocity_v2. The description explains what the computation does, but not which scenarios select this tool or when the sectorProfile option should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute monetization_score (0-21) + label + has_pricing_anchors from pricing anchors + model tags + deal cycle hint.
| Name | Required | Description | Default |
|---|---|---|---|
| dealCycle | No | instant/days/weeks/months/quarters | |
| modelTags | No | e.g. ["subscription","usage","marketplace"] | |
| pricingAnchorsCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the behavioral disclosure burden. It does clarify that this is a compute operation with defined outputs, implying a pure calculation, but it does not state whether it is read-only, what 'label' means, how inputs map to the score, or whether external data is needed.
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?
The description is a single concise sentence with the output name and range front-loaded. Every phrase adds relevant information, and there is no redundancy or unnecessary elaboration.
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 and no annotations, the description lists the main outputs but leaves 'label' undefined and does not explain how the deal cycle hint affects scoring. It is adequate for basic invocation but incomplete for a confident understanding of result semantics.
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 description coverage is 67%: dealCycle and modelTags have descriptions, but pricingAnchorsCount does not. The description maps 'pricing anchors', 'model tags', and 'deal cycle hint' to the parameters, but adds little beyond parameter names and does not explain the meaning of the deal cycle hint or the pricing anchor count behavior.
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?
The description names a specific computation (monetization_score), states its output range (0-21) and additional outputs (label, has_pricing_anchors), and identifies the input categories. It is semantically distinct from sibling compute_* tools, though it does not explicitly contrast with them.
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?
No when-to-use guidance, prerequisites, or alternatives are provided. An agent must infer from the tool name that this is for monetization scoring, and there is no explicit routing away from other compute_* tools or mention of conditions that favor this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multi-source TAM consensus. Pass 2-3 sources of market-size text. Optional estimateYear per source — when supplied, the result includes yearRange and a hasStaleData flag (true if the span exceeds 5 years). Outliers are dropped by modified Z-score over the median absolute deviation when n≥4. Returns the extracted dollar amounts + consensus median + an agreement score 0..1, where 1 means every source lands within 20% of the median.
| Name | Required | Description | Default |
|---|---|---|---|
| inputs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It reveals the outlier-removal algorithm (modified Z-score over MAD when n≥4), the conditional yearRange/hasStaleData output tied to estimateYear, and the exact output composition including the agreement-score definition. This gives the agent an accurate mental model of the computation and its edge cases.
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?
The description is three dense sentences with no filler. The first sentence states the purpose and input condition, the second covers the optional parameter effect, and the third explains the algorithm and return values. Every clause contributes new, actionable information.
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?
Since there is no output schema, the description appropriately enumerates all return components: extracted dollar amounts, consensus median, agreement score, and the optional yearRange/hasStaleData fields. It also defines the agreement score and covers the key algorithmic edge case (outlier handling only when n≥4), making the tool callable and interpretable without further documentation.
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 description coverage is 0%, so the description is the primary source of parameter meaning. It clarifies that the input objects are 'sources of market-size text,' that 2-3 such sources are expected, and that estimateYear controls the yearRange and hasStaleData output fields. This is far more informative than the bare schema, which only names source, text, and estimateYear without describing their role.
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?
The description opens with 'Multi-source TAM consensus,' a specific verb-plus-resource statement that clearly identifies the tool's job: aggregating market-size estimates from multiple text sources. The TAM focus cleanly distinguishes it from the 20 sibling compute_* tools, which address unrelated signals like budget proof, social pain, or funding momentum.
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?
The description explicitly states the expected input volume ('Pass 2-3 sources of market-size text') and explains when the optional estimateYear parameter is relevant, giving an agent a clear invocation context. It does not name alternatives or state when not to use the tool, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wave 5 N.4 — compute ppc_spend_score (0-10) + label (STRONG/CONFIRMED/WEAK/ABSENT) + market_saturation from PPC traffic projection (avgCpcUsd, totalMonthlySpendUsd, optional competitorBidders + competition). Feed numbers from dataforseo_ad_traffic.
| Name | Required | Description | Default |
|---|---|---|---|
| avgCpcUsd | Yes | ||
| competition | No | ||
| competitorBidders | No | ||
| totalMonthlySpendUsd | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description clarifies that this is a pure computation producing a score, label, and saturation value from supplied numbers. It does not disclose the scoring thresholds, handling of missing optional parameters, or return structure, which leaves some behavior implicit.
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?
The description is a single dense sentence that front-loads the primary output and includes all relevant inputs. The 'Wave 5 N.4 —' prefix is process metadata that adds little, but the body is concise and free of filler.
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?
Given no annotations, no output schema, and 0% schema coverage, the description should explain label thresholds, the nature of market_saturation, and the return shape; it does not. It is enough to locate the tool but not enough to fully predict its behavior or validate results.
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 description coverage is 0%, so the description must carry parameter semantics, but it mostly restates the names: avgCpcUsd, totalMonthlySpendUsd, and optional competitorBidders + competition. It adds the dataforseo_ad_traffic source and optionality, yet does not explain how competition or competitorBidders influence the score or what valid units/meanings are beyond the schema.
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?
The description identifies a specific computation — ppc_spend_score (0–10) plus label (STRONG/CONFIRMED/WEAK/ABSENT) and market_saturation — and names the input source. This distinguishes it from the sibling compute_* tools by PPC context and concrete outputs.
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 gives clear invocation context: feed numbers from dataforseo_ad_traffic and use the PPC traffic projection parameters. It does not explicitly exclude alternative compute_* siblings, but the PPC-specific language is enough to route an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute search_velocity_score (0-25) from Trends timeline values + rising queries count + geo region count.
| Name | Required | Description | Default |
|---|---|---|---|
| geoRegionCount | No | ||
| timelineValues | Yes | Monthly Trends values 0-100 (e.g. last 10-12 months). | |
| risingQueriesCount | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds useful behavioral context by stating the output range (0-25) and the three input components, which covers the core behavior of a pure computation tool. However, it does not explain how the score is derived, what higher scores mean, or how missing/edge-case inputs are handled.
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?
The description is a single, front-loaded sentence with no filler. It states the output metric, its range, and the relevant inputs efficiently, earning its place for a simple compute tool.
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?
For a lightweight compute tool, the description provides the essential output range and input list, and there is no output schema to explain return values. But it lacks guidance on which sibling variant to use, how the score is calculated, and edge-case behavior, leaving an agent to guess at key selection and invocation details.
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 description coverage is only 33%, so the description must compensate, but it mostly restates the parameter names. It adds 'Trends' context for timelineValues but gives no extra semantics for risingQueriesCount or geoRegionCount beyond what their names already imply, and no guidance on defaults, ranges, or relative weighting.
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?
The description identifies a specific computation ('Compute search_velocity_score') and its input components, which makes the tool's purpose clear. However, it does not differentiate this from compute_search_velocity_v2 or the many other compute_* siblings, so it misses the distinction criterion for a 5.
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?
The description implies the tool is used to compute a search velocity score, but it gives no guidance on when to choose this over compute_search_velocity_v2 or any other alternative. There are no exclusions, prerequisites, or context signals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search velocity (0-25) v2 — canonical 0.40volume + 0.30trend + 0.20intent + 0.10geo. CRITICAL: externalVolumeNorm MUST come from external sources (Amazon BSR / app store installs / job-board postings) — NOT the Trends timeline (would double-count, since Trends is itself normalized 0-100 within window). trendNorm is derived internally from trendsTimelineValues. Trends peak<50 zeroes the trend component (Yotpo SEO floor). Optional daysSinceLastSignal applies exponential freshness decay (search half-life 90d).
| Name | Required | Description | Default |
|---|---|---|---|
| intentNorm | Yes | 0-1 commercial/transactional intent ratio. | |
| geoSpreadNorm | Yes | 0-1 geographic spread (regions with interest > threshold). | |
| externalVolumeNorm | Yes | Normalized 0-1 demand volume from EXTERNAL sources (Amazon, app stores, jobs). Caller normalizes before passing. | |
| daysSinceLastSignal | No | Optional: days since most recent confirming signal. Triggers exponential freshness decay (half-life 90d). | |
| trendsTimelineValues | Yes | Monthly Trends values 0-100. Used ONLY to derive trendNorm — never as raw volume. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by revealing the internal derivation of trendNorm, the critical external-source requirement for externalVolumeNorm, the peak<50 zeroing rule, and the optional exponential freshness decay with a 90d half-life. It does not describe error conditions or return format beyond the 0-25 range, but the computational behavior is richly disclosed.
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?
The description is dense but efficient; every clause adds important information. The formula is front-loaded, followed by a critical caveat, then internal derivation, a threshold rule, and the optional decay behavior. It could be slightly more structured, but it is not padded and each sentence 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?
For a computation tool with no output schema and no annotations, the description covers the essential behavioral context: the formula, the source constraint, normalization handling, an edge-case threshold, and decay logic. The main missing piece is guidance on when to choose v2 over v1, but for invoking the tool correctly with the given inputs, the description is largely complete.
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 100%, so the baseline is 3, but the description adds meaningful semantics beyond the schema: it warns that externalVolumeNorm must NOT use Trends data to avoid double-counting, clarifies that trendNorm is derived internally from trendsTimelineValues, and explains the 90-day half-life for daysSinceLastSignal. This goes well beyond what the schema descriptions provide.
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?
The description clearly states the tool computes a 'Search velocity' score on a 0-25 scale and provides the exact weighted formula (0.40*volume + 0.30*trend + 0.20*intent + 0.10*geo). This distinguishes it as a computation tool with a precise output and makes its purpose concrete rather than merely restating the name.
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?
The description gives strong input-handling guidance (e.g., externalVolumeNorm must come from external sources, not Trends), but it never states when to use this tool versus the sibling compute_search_velocity or any other alternative. Given that a v1 sibling exists, some explicit differentiation or selection criteria would be valuable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute social_pain_score (0-30) + total mentions + dominant perspective (business/consumer/trend/mixed).
| Name | Required | Description | Default |
|---|---|---|---|
| painMentions | Yes | ||
| categoryCounts | No | ||
| intentMentions | No | ||
| urgencyMentions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It reveals the output shape and the dominant perspective enum, which is useful. However, it does not disclose edge-case behavior, how inputs influence the score, whether state changes, or what happens with incomplete category data, leaving notable behavioral gaps.
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?
The description is a single dense sentence that front-loads the primary output and includes the key output variants. Every phrase adds information, with no filler or redundant restatement of the tool name.
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?
The tool has four parameters including a nested object, no output schema, and no annotations, so the description must carry substantial context. It names the outputs but omits parameter semantics, calculation logic, defaults behavior, and how categoryCounts relates to the dominant perspective. This is insufficient for reliable invocation.
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 description coverage is 0%, so the description must compensate for parameter meaning, but it does not explain painMentions, categoryCounts, intentMentions, or urgencyMentions. It only mentions 'total mentions' and 'dominant perspective' at a high level, which does not tell the agent how to populate or interpret the parameters.
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?
The description clearly states the tool computes social_pain_score with an explicit range (0-30), total mentions, and a dominant perspective with enumerated options. It is unambiguous and distinct from sibling tools by resource and output, though it does not explicitly contrast itself with any sibling.
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?
There is no guidance on when to use this tool versus any alternative. It does not mention intended use cases, prerequisites, or suggest when another compute_* sibling might be more appropriate. The only inferred usage is from the function name, which is not explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compose composite_urgency_score (0-10) + badge (LOW/MEDIUM/HIGH/VERY_HIGH/EXTREME) from 3 sub-scores: news, pain, hiring.
| Name | Required | Description | Default |
|---|---|---|---|
| newsSignalScore | Yes | ||
| painSignalScore | Yes | ||
| hiringSignalScore | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the output shape and that the result derives from the three sub-scores, implying a pure computation, but it does not state whether the operation is side-effect-free, how the sub-scores are weighted, or what thresholds produce each badge.
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?
The description is a single concise sentence with no filler. The output is front-loaded, and the input list is clearly and completely stated.
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?
For a simple three-input deterministic computation, the description covers the essential input/output contract, especially since it names the score and badge despite the lack of an output schema. Minor gaps remain around exact output formatting and badge thresholds.
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 description coverage is 0%, so the description must compensate. It groups the three parameters as 'news, pain, hiring' and gives the 0-10 range, but it does not define the meaning of each signal score beyond what the parameter names already convey.
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?
The description clearly states the verb ('Compose'), the exact output ('composite_urgency_score' with 0-10 range and badge levels), and the three inputs. This distinguishes it from sibling compute_* tools by naming the urgency-specific result and badge.
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?
There is no explicit guidance on when to use this tool versus the many sibling compute_* tools, such as compute_lrs_composite or compute_collection_scores. The phrase 'from 3 sub-scores' implies the prerequisite inputs, but no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute x_signal_score (0-20) + recency share + positivity rate from X/Twitter mention counts.
| Name | Required | Description | Default |
|---|---|---|---|
| mentionsCount | Yes | ||
| recent7dCount | No | ||
| founderMentions | No | ||
| sentimentNegative | No | ||
| sentimentPositive | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description only says 'Compute', which implies a pure calculation but does not explicitly state that it has no side effects, whether it requires authentication, or how invalid inputs are handled. It does not disclose edge-case behavior such as zero-count division.
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?
The description is a single concise sentence with no redundant phrasing. It efficiently conveys the core computation and output components.
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?
No output schema is provided, and the description only names the outputs without specifying their types, order, or format. It also does not clarify whether the optional parameters are required to produce meaningful results or what happens when only 'mentionsCount' is supplied.
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?
The schema provides parameter names and minimum values but no descriptions, and the description only loosely ties the inputs to 'mention counts' and outputs. It does not explain the role of 'founderMentions' or exactly how 'recent7dCount', 'sentimentPositive', and 'sentimentNegative' map to recency share and positivity rate.
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?
The description clearly states a specific action ('compute') and identifies the resource/result ('x_signal_score (0-20) + recency share + positivity rate') from X/Twitter mention counts. It is distinct from sibling compute_* tools because it specifically targets X/Twitter mention data.
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?
The description implies use when X/Twitter mention counts are available and a signal score is needed, but it does not explicitly state when to prefer this tool over the many sibling compute_* tools. No conditions, prerequisites, or alternative-selection guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Derive a falsifiable, data-driven list of kill criteria from upstream signals — the outputs of validate_unit_economics and compute_dealbreakers_v2, plus an ICP drift count. Returns one row per rule with {rule, threshold, status, evidence?}, where status is tripped_now / monitor / cleared. Replaces prose kill criteria, which are tautologies that can never fire.
| Name | Required | Description | Default |
|---|---|---|---|
| unitEcon | No | The result of validate_unit_economics. | |
| dealbreakers | No | The result of compute_dealbreakers_v2. | |
| icpDriftCount | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses the return shape ({rule, threshold, status, evidence?}), enumerates the possible status values, and signals pure derivation behavior through 'derive' and 'returns'. It could go further by explaining how thresholds or statuses are decided, but the provided behavioral and output information is substantial for a compute-style tool.
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?
Three sentences with no filler. The main action and inputs are front-loaded, then the return format, then a purposeful note about why prose criteria are inferior. Every sentence contributes necessary information, and the structure is easy to scan.
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?
For a tool with three inputs, no annotations, and no output schema, the description covers the key invocation details: what it does, what inputs it expects, and what it returns. It does not define the semantics of 'tripped_now / monitor / cleared' or how thresholds are determined, but it gives enough shape for an agent to call it correctly and interpret the result at a high level.
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 67%, and the schema descriptions for unitEcon and dealbreakers are minimal ('The result of ...'). The description adds meaning by naming the upstream tools and framing all three inputs as 'upstream signals'. It also gives meaning to icpDriftCount as an 'ICP drift count', which the schema lacks. This compensates for the schema gaps and helps the agent understand what to pass.
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?
The description states a specific verb ('Derive') and resource ('a falsifiable, data-driven list of kill criteria') and clearly identifies the upstream inputs. It also differentiates itself from siblings by naming two upstream tools and explicitly contrasting with prose kill criteria, so an agent can tell it apart from compute_dealbreakers_v2 and similar compute tools.
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?
The description gives clear context: use this after validate_unit_economics and compute_dealbreakers_v2 have produced outputs, and when an ICP drift count is available. It also says it 'replaces prose kill criteria', which is an implied when-not. It does not explicitly name alternatives or list exclusion conditions, but the input-dependency guidance is strong enough for an agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sanity-check a unit-economics row before publishing it in a business-model slide. Catches the math-drift class of failures (customers × ARPU ≠ revenue), enforces the LTV/CAC ≥ 1.5 floor, the cohort-positivity check, and CAC payback bounds. Returns {ok, errors[{rule, severity, detail}], derived{ratios}}. Skills MUST regenerate the row when ok=false (block-severity errors); warn-severity errors should be surfaced in the final report but do not gate publication. No LLM calls.
| Name | Required | Description | Default |
|---|---|---|---|
| cac | No | ||
| ltv | No | ||
| arpu | Yes | ||
| customers | Yes | ||
| grossMargin | No | ||
| monthlyChurn | No | ||
| annualRevenue | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers: it names the validation rules, the exact return shape, the severity semantics, and even the deterministic 'No LLM calls' behavior. This gives agents a clear model of what the tool will and will not do.
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?
The description is dense but every sentence earns its place: purpose, checks, return format, severity handling, and determinism. There is no filler or repetition, and the most important scoping information is front-loaded.
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?
For a complex 7-parameter validator with no annotations and no output schema, the description is unusually complete: it states the checks, result shape, and severity policy. The remaining gap is that two named checks ('cohort-positivity' and 'CAC payback bounds') are not fully defined, leaving some ambiguity about how optional parameters factor into them.
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 must compensate. It adds real meaning by connecting customers, arpu, and annualRevenue through the math-drift check, and ltv/cac through the ratio floor. However, grossMargin and monthlyChurn are only indirectly implied by 'cohort-positivity' and 'CAC payback bounds', and their exact semantics are not spelled out.
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?
The description opens with a specific verb and resource: 'Sanity-check a unit-economics row before publishing it in a business-model slide.' It then enumerates the exact checks (math drift, LTV/CAC floor, cohort positivity, CAC payback), making the tool's role unmistakable and distinct from the sibling compute_* signal tools.
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 clearly states when to use the tool ('before publishing it in a business-model slide') and how to react to results (regenerate on block-severity errors, only surface warning-severity errors). It does not explicitly name alternative tools or spell out when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0compute_barriercompute_budget_proofcompute_build_complexitycompute_collection_scorescompute_crossed_matrixcompute_dealbreakers_v2compute_funding_momentumcompute_hiring_demandcompute_lrs_compositecompute_lrs_composite_v2compute_monetizationcompute_multi_source_tamcompute_ppc_spend_signalcompute_search_velocitycompute_search_velocity_v2compute_social_paincompute_urgency_compositecompute_x_signalderive_kill_criteriavalidate_unit_economicsScored across 20 tools
Several tools have unclear boundaries: compute_lrs_composite vs compute_lrs_composite_v2 and compute_search_velocity vs compute_search_velocity_v2 compute the same metric under different methodologies, while compute_crossed_matrix is explicitly same-input as compute_dealbreakers_v2. The detailed descriptions help, but the agent still needs versioning and nuance to avoid misselection.
Nearly every tool follows the same snake_case verb_noun pattern, either compute_<metric> or derive_/validate_<object>, and version suffixes like _v2 are used consistently. This makes the namespace highly predictable despite the large number of tools.
20 tools is at the heavy end for a single server, and the v1/v2 duplicate pairs inflate the count without adding clear separate domains. Most tools do have a specific computation, so the count is not unreasonable, but it feels borderline.
The set covers the full idea-audit arc: individual signals, composite scores, unit economics validation, and kill criteria. Minor gaps exist, such as no standalone news sub-score and legacy v1 tools creating ambiguous coverage, but agents can still assemble a complete workflow.
Rebuilds the scores real systems run on you — credit, actuarial, lending — in the open, cited.
Read-only, deterministic AI triage and readiness tools implementing Sophon's published rubrics.
Score business ideas on six live market signals. Launch Readiness Score (LRS) for AI agents.
Deterministic sealed verdicts on public claims and startup ideas (0-LLM claim-safety guardian).
