Click on "Install 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 github:inite-ai/ideaudit-mcpThe npm name is @inite/ideaudit-tools and it is not published yet, so the
line above installs from this repository instead. Both give you the same
server; when the package lands, npx -y @inite/ideaudit-tools becomes the
shorter form and this line keeps working.
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?
With no annotations provided, the description carries the full burden. It discloses the input-to-output relationship and the exact output shape, but it does not reveal which end of the 0-24 scale indicates a high barrier, what thresholds map to each label, or how omitted optional parameters (serpNoise, adjacentCompetitorCount) affect the result. Honest but incomplete.
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?
A single dense sentence with zero filler. The output contract and input sources are front-loaded, and every element carries information — no wasted words.
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 does need to explain the return value, and it does state the score range and labels. However, it omits interpretation guidance — whether a high barrier_score is favorable, what the labels mean in decision terms, and what happens at boundary inputs. Adequate as an API contract but thin on context.
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 partially does by mapping 'competitor counts' to the two count parameters and 'SERP noise fraction' to serpNoise. However, it does not clarify the relative roles or weights of direct vs adjacent competitors, nor the meaning of the serpNoise fraction in the computation.
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 verb ('Compute'), a precise resource (barrier_score), the output contract (0-24 score plus a four-value label set), and the inputs (competitor counts + SERP noise fraction). This clearly differentiates it from the 20 sibling compute_* tools, which all target different metrics.
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 on when to use this tool vs alternatives such as compute_multi_source_tam or compute_dealbreakers_v2. In a sibling group of 20 similar compute_* tools, the description provides no routing context, no prerequisites, and no exclusion criteria.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that the tool derives a score, label, and purchase-intent percentage from pricing, review-site, and intent-mention signals, which is honest about its main computation. However, it does not disclose how missing optional inputs are handled, how labels are assigned, or what role the hasNamedPricing boolean plays.
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 outputs and then lists the contributing signal types. Every word adds useful information, and there is no filler, repetition, or unnecessary detail.
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 stateless computation tool, the description captures the core inputs and outputs in a compact way. Still, the lack of an output schema and annotations means more burden falls on the description; it does not explain the hasNamedPricing parameter, label thresholds, or edge-case behavior, leaving an agent to guess at some 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 0%, so the description must add parameter meaning on its own. It maps pricing hits, review-site hits, and intent mentions to three of the four schema parameters, which is helpful. It omits hasNamedPricing entirely, and the schema property names, though reasonably self-explanatory, are not enough to fully explain the boolean's influence on the calculation.
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 verb ('Compute'), a specific resource ('budget_proof_score'), and the exact outputs (score, label, purchase_intent_pct). It also identifies the input signal classes, making the tool's purpose clear even among many compute_* siblings. It does not explicitly contrast itself with siblings, but the resource name and outputs provide enough distinction.
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 any of the sibling compute_* tools or other alternatives. There are no inclusion/exclusion criteria, no context about typical workflows, and no mention of prerequisites. The description only says what the tool does, not when an agent should choose it.
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?
No annotations are provided, so the description carries the behavioral burden. It does disclose the output range, direction, and the existence of a per-factor breakdown, and it lists hard tags. However, it does not describe how inputs are combined, whether there are side effects, or how the hard tags affect the penalty.
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 sentences with no filler. The main output is front-loaded, and the hard-tag list is compactly appended.
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, no annotations, and no parameter descriptions, the tool needs more context than this. Missing details include how externalApisCount and integrationsCount contribute, what the per-factor breakdown looks like, and what happens when stackComplexityTags contains unknown values.
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 partially documents stackComplexityTags by listing the hard-tag values, but externalApisCount and integrationsCount are not described at all beyond their schema names and minimums. The meaning of these parameters and their impact on the penalty remain unclear.
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 names the computed resource (build_complexity_penalty), its scale and direction (0-10, higher=worse), and the per-factor breakdown output. This is specific enough to distinguish it from the many sibling compute_* tools, which target 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?
No explicit guidance is given for when this tool should be used versus alternatives such as compute_barrier or compute_dealbreakers_v2. The hard-tag list hints at relevant inputs but does not state a use case, prerequisites, or exclusions.
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 provided, the description carries the behavioral disclosure burden. It clearly states determinism ('deterministic'), side-effect-free execution ('Pure math'), and independence from external services ('No external calls'), which are valuable behavioral traits. It does not discuss failure modes or performance, but for a computation tool these are reasonable omissions.
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 exceptionally compact: two sentences pack the key facts (what is computed, the count, the value ranges, the outputs, determinism, and the no-external-calls guarantee). Every 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?
Despite lacking an output schema, the description names the major output categories (scores, badges, death reason), which is sufficient for a deterministic computation tool. The main gap is the undocumented analysisId parameter and the lack of input-shape expectations, but the overall description is reasonably complete for the tool's complexity.
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 50%: analysisId has no description, and enrichedData only has a terse 'canonical_idea signals' note. The description adds little beyond reiterating that the input is an 'enriched idea'; it does not clarify the role of analysisId or what enrichedData must contain.
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 the exact action ('Compute'), the resource ('12 deterministic collection scores'), and the output components (badges, death reason). It also specifies the input state ('for an enriched idea'), making its purpose unambiguous and distinct from the 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?
The phrase 'for an enriched idea' implies the tool should be used when enriched data is available, and 'Pure math. No external calls' gives useful context about its execution environment. However, there is no explicit guidance on when to choose this tool over sibling compute_* tools, nor any exclusions or prerequisites.
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, the description carries the behavioral burden. It explicitly says 'Never persists,' which is a strong side-effect disclosure, and it explains that the crossed verdict appears only when an observer is supplied. It could be more precise about what happens when observer is omitted, but it is not misleading.
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 concise sentences with no filler. It front-loads the output structure, then states the non-persistence behavior and intended use case. Every sentence contributes useful 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?
For a tool with 7 parameters, nested observer input, and no output schema, the description is reasonably informative but not fully complete. It explains the main outputs and use case, yet leaves ambiguity about whether the matrix is still returned when observer is omitted and does not describe the shape of the verdicts or matrix rows.
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%, and the description does not compensate by explaining stage, lensScores, sector, stageProbabilities, or the other parameters. The phrase 'same input as compute_dealbreakers_v2' provides a reference, but that alone is insufficient when most parameters are undocumented in both schema and description.
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 what the tool returns: substrate verdict, crossed verdict when an observer is supplied, and a 5-row archetype verdict matrix. It also differentiates from compute_dealbreakers_v2 by noting the same input but different output, so an agent can distinguish it from the closest 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 clear usage context: it is meant for the dashboard 'view as [archetype]' dropdown and for previewing a verdict before committing. It names compute_dealbreakers_v2 as a same-input sibling but does not explicitly state when NOT to use this tool instead of that one.
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, the description carries the full behavioral burden and mostly delivers. It discloses non-obvious decision logic: GO requires three simultaneous conditions, KILL triggers on ≥2 blockers or score<50, and the KILL gate is observer-invariant ('fatal stays fatal'). It also explains the observer-triggered crossed-product pipeline. It does not describe output format or side effects, but the core verdict semantics are 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?
The description is a single dense sentence, but every clause contributes thresholds, pipeline details, or an invariant behavior. It front-loads the methodology and key verdict rules before explaining the observer pathway. While dense, the complexity of the tool justifies the compressed structure.
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 tool with nested objects, no output schema, and no annotations, the description covers the main GO/KILL logic and observer pipeline well. However, it omits the return-value shape and the meaning of several optional inputs such as sector, stageProbabilities, and contradiction flags. It is sufficient for invoking with required parameters but incomplete for full understanding of all inputs and outputs.
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 must compensate for the missing parameter documentation. It adds meaning to stage, lensScores, confidence, and observer, but it does not clarify sector, stageProbabilities, hasMajorContradiction, or unresolvedContradictions. The term 'blockers' is used without mapping it to a schema field, leaving several inputs semantically opaque.
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, specifying the GO conditions (score≥80, zero red flags, avg confidence≥0.6) and a KILL gate. It conveys an algorithm centered on stage-aware weights and confidence-weighted lens scoring, which is specific enough to distinguish it from generic compute siblings. However, it does not explicitly name the return object or call out how it differs from closely related tools like derive_kill_criteria.
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 choose this tool over alternatives such as compute_crossed_matrix or derive_kill_criteria. The only usage hint is the conditional observer behavior: when observer is omitted, only the substrate verdict is returned. No exclusions, prerequisites, or alternate-tool routing are provided, so the agent must infer selection indirectly.
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 behavioral burden. It reveals the weighted nature of the calculation and the exact output shape, which is useful. However, it does not explain how weights are applied, what happens when hits are absent, whether recent30dHits affects the score, or any 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?
The description is a single, front-loaded sentence that states the output, range, badge scheme, and input concept with no wasted words. Every element serves a purpose.
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 is adequate for recognizing that this computes a momentum score from tiered hit counts, but it is incomplete for confident invocation. It omits the optional recent30dHits parameter, fails to define the tier semantics, and provides no weighting formula. Since there is no output schema, the description also leaves the exact mapping between score and badge unexplained.
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 the schema's silence. It loosely maps 'tier-weighted funding-article hit counts' to the hitsByTier object, but it does not explain the roles of tier_1, regional, vertical, presswire, or the optional recent30dHits parameter. An agent would not know how to populate the inputs correctly from the description alone.
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 funding_momentum_score on a 0-10 scale plus a HOT/WARM/COOL/COLD badge from tier-weighted funding-article hit counts. It names the resource and output format, making the tool's main purpose unmistakable, though it does not explicitly differentiate itself from the many 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?
No guidance is given about when to use this tool versus alternatives like compute_urgency_composite or compute_collection_scores. The description implies the input scenario (having tiered funding-article hit counts), but it never states exclusions or preferred situations, leaving an agent to guess among many similar compute 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?
With no annotations provided, the description carries the full burden and does disclose the computation basis and external registry dependency. However, it does not describe return shape, error behavior, or edge cases such as empty site arrays, so behavioral transparency is only partially addressed.
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 entire description is one focused sentence with no filler. The core action, input, and output range are front-loaded, and the registry pointer is included efficiently.
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 essential input semantics, priority source, and score range, which is adequate for a simple single-parameter compute tool. However, with no output schema and no annotations, the lack of explicit return format and edge-case behavior leaves some gaps for an autonomous agent.
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 property descriptions are absent (0% coverage), so the description must compensate. It does explain that 'sites' represent ATS hit counts weighted by priority and references the priority registry, but it stops short of defining the exact weighting/aggregation formula, leaving some parameter semantics 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 uses a specific verb ('Compute') and names the exact resource ('hiring_demand_score') along with its output range (0-10). It also identifies the input as 'priority-weighted ATS site hit counts,' which clearly separates it from the sibling compute_* tools that target different metrics.
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 when to use this tool: whenever a hiring-demand score must be derived from ATS hit counts. It also gives a useful pointer to the registry for priorities, but it does not explicitly state when to choose this tool over alternatives or mention any exclusions.
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 present, the description carries the full transparency burden and it does reasonably well: it discloses the output components (0-100 score, label, eligibility flag, breakdown) and the weights applied. It does not reveal label thresholds or eligibility-flag logic, but the essential computation behavior is visible.
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 compact sentences deliver the key facts with no filler. The output composition is front-loaded and the weighting details are placed directly after, making the tool's behavior 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?
The description covers the core purpose and weights, but there is no output schema and no explanation of how labels, leaderboard eligibility, or the sub-percent breakdown are derived. Given the absence of annotations and output schema, an agent would still have to infer some important computation 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 0%, but the property names themselves are fairly self-explanatory and the min/max ranges are in the schema. The description adds meaning by listing weights ('sv 0.25, sp 0.30, barrier 0.25, monetization 0.20'), though it uses abbreviations that are not explicitly mapped to the schema property names.
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 clear action ('Compose') and an identifiable resource: a final LRS score with a label, eligibility flag, and breakdown. It also includes the weighting scheme, which sharpens what the tool computes. However, it does not differentiate itself from the sibling compute_lrs_composite_v2, so an agent may not know which variant to choose.
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 alternatives such as compute_lrs_composite_v2 or the individual component tools. The description implies the tool should be used after subscores are available, but it never states prerequisites or exclusions.
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 carries the full burden and does a strong job: it discloses exact default weights, that both weighted and equal-weight baselines are returned, that a buildComplexityPenalty is subtracted, and how an opt-in sectorProfile changes weights. It stops short of describing edge cases or exact output structure, but the key behaviors are 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?
The description is dense and mostly front-loaded, moving from purpose to weights to penalty to labels without wasted sentences. Some jargon ('SV', 'X-Signal') is compact but not fully expanded, and the run-on structure could be easier to parse, yet it remains efficient.
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 output schema, the description explains that both weighted and equal-weight results are returned but not the exact output shape or field names. It also does not state defaults for omitted optional parameters like buildComplexityPenalty or sectorProfile, or fully enumerate the reshuffled weight sets for each sector profile. These are meaningful gaps for a calculation tool with 8 parameters.
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 only 13%, so the description must compensate, and it adds substantial meaning: it maps the six required scores to abbreviations, gives exact default weights, explains the penalty parameter, and describes the sectorProfile reshuffling behavior. It does not deeply define each score's conceptual meaning, but the parameter names plus weight assignments are largely sufficient for correct invocation.
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 an LRS composite v2 score from six named components, which is a specific verb+resource combination. However, it does not differentiate v2 from the sibling compute_lrs_composite, so an agent cannot tell what changed between versions from the description alone.
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 explicit guidance is given about when to use this tool versus alternatives like compute_lrs_composite or other composite tools. The description implies usage by defining weights and optional sector profiles, but it never states 'use this when...' or 'use X instead when...'.
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?
With no annotations, the description carries the burden; it transparently states the core computation and output shape (score, label, boolean). It doesn't describe scoring rules, label values, edge cases, or whether inputs beyond pricingAnchorsCount are truly optional.
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 single sentence, front-loaded with the output and then the inputs; every term earns its place. There is no fluff or repetition of schema details.
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 3-param, no-output-schema compute tool, the description gives the output components and score range plus the input mapping. It is slightly thin on label semantics and formula, but sufficient for an agent to invoke it correctly with the required pricingAnchorsCount.
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 covers dealCycle and modelTags (67%), and the description maps each parameter into the computation: pricing anchors → pricingAnchorsCount, model tags, and deal cycle hint. It adds meaning to pricingAnchorsCount, which the schema does not describe.
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 (Compute), the resource (monetization score), its range (0-21), and the companion outputs label and has_pricing_anchors. The domain clearly separates it from the compute_* siblings, though it does not name an alternative or contrast.
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?
Context is implied: use this when a monetization score is needed from pricing anchors, model tags, and deal cycle. It gives no explicit when-not or alternative routing, and the sibling list contains many compute_* tools, so an agent must infer selection from the name/domain.
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?
There are no annotations, so the description carries the full behavioral transparency burden and does so thoroughly. It discloses return components, the hasStaleData flag semantics, the outlier-removal rule with modified Z-score/MAD at n≥4, and the exact meaning of an agreement score of 1. This gives the agent a strong model of what will happen.
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?
Every sentence contributes operational value: input count, optional parameter behavior, outlier handling, and return semantics. The purpose is front-loaded and there is no filler or 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 covers outputs and algorithms unusually well, but it contains an internal inconsistency: it instructs the agent to pass 2-3 sources while also specifying outlier behavior when n≥4, which would be unreachable under that stated limit. It also omits behavior for fewer than 2 sources and does not clarify the `source` field's intended meaning, which could lead to incorrect 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?
With schema description coverage at 0%, the description compensates by explaining the input shape: 2-3 sources of market-size text, optional per-source estimateYear, and the downstream effect of supplying estimateYear. It could more explicitly describe the `source` and `text` fields, but their meaning is recoverable from context.
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 a specific operation: multi-source TAM consensus using market-size text. It distinguishes itself from the many sibling compute_* tools by naming TAM specifically and describing extraction, aggregation, and agreement scoring. This goes well beyond restating the tool 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 tells the agent to pass 2-3 sources of market-size text and explains when the optional estimateYear is relevant. It does not name alternative tools or state explicit when-not-to-use conditions, but the usage context is clear enough to select this tool among its siblings.
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?
No annotations are provided, so the description carries the full burden. It does disclose output shape and labels, which is useful, but it does not describe how the score is computed, how optional parameters affect behavior, or whether missing optional inputs change the output.
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 core description is compact and front-loaded, conveying purpose, inputs, and outputs in a single sentence. The leading 'Wave 5 N.4 —' label is internal noise that does not help an agent, so it is not perfect.
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 there is no output schema, the description helpfully names the main returned pieces (score, label, market_saturation) and the input source. It omits the exact return structure, scoring thresholds, and handling of optional inputs, so an agent still lacks some context needed to fully interpret or validate the result.
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 names all four parameters (avgCpcUsd, totalMonthlySpendUsd, optional competitorBidders + competition) and their source context, but it does not define the meaning or scale of 'competition' or how the optional parameters influence the result.
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 output: ppc_spend_score (0-10) plus label (STRONG/CONFIRMED/WEAK/ABSENT) and market_saturation, derived from PPC traffic projection. It is distinguishable from sibling compute_* tools by the PPC spend domain, though the tool name says 'signal' while the description says 'score', creating minor ambiguity.
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 implies when to use the tool by saying 'Feed numbers from dataforseo_ad_traffic' and framing inputs as a 'PPC traffic projection'. However, it does not explicitly state when not to use it or how it differs from sibling compute tools.
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 but only says a score is computed from inputs. It does not disclose how inputs are combined, missing-value behavior, or any side effects, leaving the tool's behavior largely 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 conveys action, resource, inputs, and output range with no filler or redundancy. 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?
For a simple compute tool, naming all inputs and the output range is enough for a basic call. However, the absence of an output schema, annotations, and any guidance distinguishing this from compute_search_velocity_v2 leaves meaningful gaps.
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 only 33%, and the description mostly restates the parameter names in readable form ('Timeline values', 'rising queries count', 'geo region count') without adding units, defaults, roles, or computation details. The output range is helpful, but parameter meaning is not meaningfully expanded.
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 operation (compute) and resource (search_velocity_score), enumerates all three inputs, and states the 0-25 output range. However, it does not differentiate this tool from the sibling compute_search_velocity_v2, so it misses the top tier.
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 on when to use this tool versus alternatives, especially compute_search_velocity_v2. The description states what it computes but gives no context for choosing it over the many sibling compute_* functions.
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 reveals the scoring formula, the internal derivation of trendNorm, the peak<50 zeroing behavior, and the exponential freshness decay. This goes well beyond a generic 'computes a score' statement, though it does not describe the exact return shape or edge-case handling.
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, opening with the formula and then delivering the most critical usage caveat in an attention-grabbing 'CRITICAL' marker. Every sentence contributes operational information; the only minor issue is that the caveats run together in a fairly long paragraph rather than being cleanly separated.
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 computational scoring tool with five parameters, no annotations, and no output schema, this description is quite complete: it covers the formula, normalization source rules, derived trend behavior, and optional decay. It does not explain the exact output structure or any validation/error behavior, but the 0-25 range and compute-only nature make the missing pieces less critical.
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 100%, so the baseline is 3, but the description adds meaningful semantics: formula weights, cross-parameter relationships, source restrictions for externalVolumeNorm, the trend floor threshold, and the 90-day decay half-life. This gives an agent actionable meaning beyond the schema fields themselves.
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 operation: compute search velocity on a 0-25 scale using a weighted formula. It names the resource (search velocity) and the exact inputs, so an agent knows what the tool does. It does not explicitly contrast itself with the sibling compute_search_velocity, relying on the 'v2' and 'canonical' wording to imply distinction.
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 operational guidance: externalVolumeNorm must come from external sources and must not come from the Trends timeline, with a concrete double-counting rationale. It also explains when the trend component is zeroed and how the optional decay parameter behaves. It stops short of naming alternative sibling tools or explicitly stating 'use this when...', but the context is clear.
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?
Annotations are not provided, so the description carries the full burden of behavioral disclosure. It states only the outputs and gives no information about side effects, required inputs, computation logic, error conditions, or return structure. There is no contradiction, but the transparency is minimal.
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 conveys the core purpose efficiently. It lists all key outputs with scant waste, though its brevity leaves important behavioral and parameter details unaddressed.
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 four parameters, a required painMentions field, nested categoryCounts, no output schema, and no annotations, the description is incomplete. It defines what the tool returns but not how inputs map to outputs, leaving an agent to guess parameter semantics and the exact return shape.
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% and the description does not explain any of the four parameters. It indirectly hints at categories through 'dominant perspective (business/consumer/trend/mixed)', which maps to categoryCounts, but intentMentions and urgencyMentions remain unexplained.
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?
Description uses the specific verb 'Compute' and clearly identifies the output: social_pain_score (0-30), total mentions, and dominant perspective. The resource is unambiguous and distinct from siblings like compute_search_velocity, though no explicit sibling differentiation is stated.
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 information about when to use this tool versus alternatives, what conditions warrant it, or what prerequisites exist. The sentence implies it is used to compute social pain metrics, but gives no exclusion criteria or context that would help an agent choose among the many compute_* siblings.
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 provided, the description carries the full burden of disclosing behavior. It does disclose the essential transformation: three sub-scores become a composite score and a categorical badge. However, it does not explain how the composite is computed, how the badge thresholds are chosen, or whether inputs must be normalized beyond the schema's range constraints. This is adequate as a minimal behavioral contract but leaves 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 compact sentence with no filler. It front-loads the output (composite score and badge) and then specifies the inputs. Every element in the sentence carries useful information, and no words are wasted.
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?
There is no output schema or annotations, so the description must explain return values and invocation context. It does mention both outputs and all three inputs, which is useful. But it omits the computation method, the meaning of the sub-scores, and any caveats about valid inputs or edge cases. For a pure compute tool this is a workable but not fully complete description.
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 no descriptions for any of the three parameters, so the description's identification of 'news, pain, hiring' as sub-scores adds some semantic meaning that is absent from the schema. However, the description does not elaborate on what each signal score represents, how to interpret higher values, or how the three scores are combined. The parameter names are self-descriptive, so the added value beyond the schema is limited.
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 begins with the concrete verb 'Compose' and specifies the exact resource produced: composite_urgency_score (0-10) plus a badge with five enumerated values. It also names the three required inputs (news, pain, hiring), which makes the tool readily distinguishable from the many other compute_* siblings. The unique combination of urgency composite and the news/pain/hiring sub-scores leaves no ambiguity about what this tool does.
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 what the tool does but provides no guidance on when to choose it over sibling tools such as compute_lrs_composite or compute_collection_scores. There are no explicit alternatives, exclusions, or conditions such as 'use when you need the composite urgency score and already have the three sub-scores.' Usage context is only implicit from the tool name and description.
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?
With no annotations, the description carries the full burden and it does convey that this is a pure computation producing three named outputs from mention counts. However, it does not disclose how recency share and positivity rate are derived from the optional parameters, how missing optional inputs are handled, or the return format. The core behavior is clear, but the details are thin.
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?
A single sentence that front-loads the primary output and score range, then the secondary outputs, then the data source. There is no filler, redundancy, or wasted wording; every word carries 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?
This tool has 5 undocumented parameters, no annotations, and no output schema, so the description must carry a heavy load. It helpfully names the three outputs since no output schema exists, but it leaves parameter-level semantics (especially founderMentions) and the exact derivation logic unexplained. An agent cannot confidently determine correct input construction or interpret the 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 compensate. It provides context for mentionsCount as 'X/Twitter mention counts' and implies recent7dCount feeds recency share and that sentiment parameters feed positivity rate. However, founderMentions is never mapped to any metric, and no parameter is explicitly defined, so compensation is only partial.
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 and resource: 'Compute x_signal_score (0-20) + recency share + positivity rate from X/Twitter mention counts.' It names the exact outputs, the score range, and the data source, so an agent knows precisely what the tool produces. It does not explicitly differentiate from the 18 sibling compute_* tools, but the specific output metrics 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?
There is no guidance on when to use this tool versus alternatives like compute_social_pain or compute_collection_scores, no exclusions, and no prerequisites or context for when X/Twitter mention counts are the right input. The description states only what it computes, never when it should be chosen.
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 behavioral burden. It discloses the output shape (one row per rule with rule, threshold, status, evidence?), enumerates status values, and explains the design intent of falsifiable rules. It does not mention edge cases or side effects, but the derive verb and transformation nature make the tool's read-only, computational behavior 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?
Two sentences, front-loaded with the core action and input sources, then the output contract. The final clause about replacing prose kill criteria earns its place by giving the rationale for the tool's existence without adding fluff.
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 derivation tool with no output schema and no annotations, the description provides the essential output contract and input provenance. It is slightly incomplete in that it does not specify behavior when no inputs are provided or whether all three inputs are required, but the overall guidance is sufficient for an agent to invoke it correctly in the intended flow.
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 maps unitEcon and dealbreakers to the outputs of named sibling tools and adds meaning to icpDriftCount, which has no schema description. With 67% schema coverage, the description compensates for the undocumented parameter and clarifies the relationship between all three inputs.
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'), a concrete result ('falsifiable, data-driven list of kill criteria'), and the exact upstream inputs. It clearly differentiates from the sibling compute_* tools by describing an output that is a set of rules with statuses, not a single computed metric.
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 explicitly identifies when the tool should be used: after validate_unit_economics and compute_dealbreakers_v2, and as a replacement for prose kill criteria. It does not enumerate exclusions or alternative tools, but the upstream-signal framing gives sufficient usage context.
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 provided, the description carries the full burden, and it does so thoroughly. It discloses the exact return shape, the severity model with consequences for each severity class, the validation rules enforced, and the deterministic nature ('No LLM calls').
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 dense, information-rich sentences cover purpose, validation rules, return format, action guidance, and determinism. Every sentence earns its place and there is no filler or repetition of schema content.
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 is sufficiently complete for a validation tool with no output schema: it specifies the return structure and behavioral outcomes. The main minor gap is lack of explicit per-parameter clarification for optional fields, but the overall context is strong enough for an agent to invoke the 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 meaningfully explains the roles of customers, ARPU, annualRevenue, LTV, and CAC through the stated formulas and validation rules. However, grossMargin and monthlyChurn are only indirectly inferable from 'CAC payback bounds' and 'cohort-positivity check', leaving their exact semantics partially unspecified.
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 purpose with a specific verb ('Sanity-check') and resource ('a unit-economics row'), and places it in a concrete context ('before publishing it in a business-model slide'). It also distinguishes itself from the sibling compute_* tools by focusing on validation rather than signal computation.
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 usage context ('before publishing') and defines the decision flow: block-severity errors require regeneration, warn-severity errors only need surfacing. It does not explicitly name alternatives or when not to use it, but the validation-vs-computation distinction is strongly implied by its content.
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. Dates show when Glama detected each change.
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_economicsSeveral 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
Deterministic sealed verdicts on public claims and startup ideas (0-LLM claim-safety guardian).
SEC, Congress, FDA, crypto, app reviews and live jobs: scored signals. 18 tools, free flagship.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/inite-ai/ideaudit-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
