ASX dilution data for any listed company, from its own filings: dilution risk level, capital raise history, options and rights overhang, cash runway and placement capacity. Two tools are free and keyless; the rest need a DilutionLens Pro key.
Scored across 6 tools
Each tool targets a distinct data view: cash runway, dilution snapshot, issuance timeline, options register, raise history, and universe screening. There is some conceptual overlap between the issuance timeline and the structured raise/options tools, but the descriptions clarify that one is a cited filing timeline while the others are structured registers.
Five tools follow a clear get_<resource> pattern, making their purpose predictable. The single 'screen' tool is a reasonable exception for a discovery/search operation, but it is a minor deviation from the otherwise consistent convention.
Six tools is well-scoped for a focused ASX dilution and cash-analysis server. Each tool covers a distinct stage of company research or universe discovery, with no redundant or trivial entries.
The surface covers the core workflow: screen companies, inspect dilution risk, cash runway, raises, issuance events, and option/debt overhang. Minor gaps exist around company metadata or filing-level detail, but agents can work around them using the provided tools.
Cash, burn and cover history (IQ Cash) for one ASX company: quarterly 4C/5B rows and, for half-year filers, 4D/4E rows (period_months says which; their net flow is operating only, averaged per quarter). Identical to the paid page's cash detail.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | One ASX ticker code, e.g. BHP. One company per call — there is no batch form. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds meaningful behavioral context: it explains the data structure (quarterly vs half-year filers, period_months indicator, operating-only net flow averaged per quarter) and that results are identical to the paid page. This goes beyond the annotations without contradicting them.
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 zero fluff. The main purpose is front-loaded, and the second sentence adds a useful reference point (paid page). Every word contributes, and the structure is 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?
For a single-parameter read-only tool with no output schema, the description gives a strong sense of what data to expect: specific rows, period_months semantics, and operating-only net flow. It does not describe the exact output structure, but the coverage is sufficient for an agent to understand the tool's function and call it 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?
The schema provides 100% coverage for the single parameter 'ticker' with a clear description, including the note that there is no batch form. The tool description adds no parameter-specific information beyond what the schema already states, so it meets the baseline for high schema coverage.
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: 'Cash, burn and cover history' for one ASX company. It enumerates the exact data rows (4C/5B, 4D/4E) and notes it matches the paid page's cash detail, making the purpose unambiguous and distinct from sibling tools like get_dilution_snapshot or get_options.
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 provides no explicit guidance on when to use this tool versus alternatives. It does not name any sibling tool or state conditions for selection. The specific scope ('cash runway') implies usage, but without exclusions or comparisons, an agent must infer when this is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Headline dilution metrics for one ASX company — risk level, cash cover band, market cap, 12-month raise count and options & rights overhang % (the JSON key remains max_dilution_pct — a contract). Mirrors the free company page. Works without a key, ~20 calls/day.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | One ASX ticker code, e.g. BHP. One company per call — there is no batch form. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context: it works without a key, has a ~20 calls/day rate limit, and reveals a contract detail (the JSON key max_dilution_pct remains stable). It also notes it mirrors the free company page, implying a specific data source. These details go beyond the annotations and aid an agent in understanding runtime 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 compact two-sentence structure with no filler. The first sentence states purpose and metrics, the second conveys the contract note and auth/rate-limit details. Every sentence carries essential information, and the purpose is front-loaded. This is an efficient, well-organized description.
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 single-parameter tool with no output schema, the description covers the essential operational details: what metrics are returned, the contract key, auth requirement, rate limit, and data source. It lacks explicit units or formatting for the metrics (e.g., currency for market cap), but that is not critical for invoking the tool. It is sufficiently complete for an agent to call it 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 100% – the ticker parameter already has a clear description ('One ASX ticker code, e.g. BHP. One company per call — there is no batch form.'). The tool description reiterates 'one ASX company' but adds no new syntax or format details. Since the schema fully documents the parameter, the description adds no extra meaning, warranting the baseline 3.
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 ('get') and a clear resource ('dilution snapshot for one ASX company'), then enumerates the exact metrics returned (risk level, cash cover band, market cap, 12-month raise count, options & rights overhang %). This is specific enough to distinguish from siblings like get_cash_runway or get_options without naming 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?
The description clarifies the tool's scope ('headline dilution metrics') and notes it mirrors the free company page, but it does not explicitly state when to use this tool versus siblings like get_issuance_timeline or get_raise_history. The '~20 calls/day' hint suggests a lightweight snapshot, but no direct alternatives or exclusions are provided. Usage is implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The share-issuance timeline for one ASX company — every issuance-relevant filing, dated and cited. Identical to the paid page's timeline.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | One ASX ticker code, e.g. BHP. One company per call — there is no batch form. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds output scope but no behavioral traits beyond that; it does not contradict the annotations. This is a standard, adequate level given rich annotations.
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 the core resource and scope front-loaded. The second sentence ('Identical to the paid page's timeline') is somewhat marginal for an agent but not distracting; overall it's concise and structured well.
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?
Without an output schema, the description gives a useful high-level outline of the returned data (dated and cited filings), but it does not specify structure, ordering, or filing types. It is adequate for a single-parameter read-only tool, but gaps remain.
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% and the ticker parameter is already well documented (one ticker, no batch). The tool description adds nothing beyond the schema, so the baseline 3 is appropriate.
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 (share-issuance timeline for one ASX company) and the content (every issuance-relevant filing, dated and cited). It is specific and not a tautology, but it does not explicitly differentiate from sibling tools like get_raise_history, so it stops short of 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 when to use the tool (when you need a company's issuance timeline) and the schema adds a concrete constraint (one company per call, no batch form). However, there is no explicit guidance about alternatives or when not to use it, so it does not fully meet the 4-bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The option and convertible register for one ASX company — every line's code, security kind (options, performance rights, warrants, rights), type (price-triggered, condition-triggered, converts on terms for equity convertibles such as convertible preference shares, not classified), exercise price, expiry and quantity. Debt convertibles (convertible notes, bonds, debentures, hybrids) are a separate list, debt_convertibles: code, kind, count of notes or units (NOT shares), maturity and filing; they are in no overhang or in-the-money figure. Free and keyless (~20 calls/day), identical to the free company page. With a paid API key the same call also returns each line's in-the-money value, the filing's own description and section, and the quantities and strikes as filed before any consolidation rebase — identical to the paid page's options block.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | One ASX ticker code, e.g. BHP. One company per call — there is no batch form. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations: discloses a free keyless tier with a ~20 calls/day cap, states that a paid key silently enriches the same call with in-the-money values, filing description/section, and pre-consolidation strikes. It also warns that debt-convertible counts are units, NOT shares, and are excluded from overhang and in-the-money figures — exactly the kind of exclusion an agent could otherwise misreport.
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?
Front-loads the resource and scope, then layers the exclusion and the tier behaviour in a sensible order. The first sentence is a long field dump and the paid-tier sentence is somewhat sales-flavoured, but no sentence is purely 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?
There is no output schema, and the description compensates by enumerating the returned columns and distinguishing share-denominated from unit-denominated quantities. Combined with the tier and exclusion notes, an agent has everything needed to call it and interpret the result 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 coverage is 100% and the schema already states 'one ASX ticker code... no batch form,' so the description's single-company framing duplicates rather than adds. With one fully documented parameter, the baseline 3 is appropriate.
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?
Names a precise resource — the option and convertible register for one ASX company — and enumerates the returned fields (code, security kind, type, exercise price, expiry, quantity), making the boundary of the tool concrete. It also explicitly carves out debt convertibles as a separate list (`debt_convertibles`), so an agent can tell the two apart without opening a schema.
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 implied by the scope statement and the explicit pointer away from debt convertibles, but there is no guidance about when to reach for this versus the listed siblings (get_dilution_snapshot, get_cash_runway, get_issuance_timeline). The free-vs-paid tier note is useful context but is about access, not tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every capital raise on record for one ASX company: date, type, amount, issue price, shares issued, brokers and stated purpose. Identical to the paid page's raise history.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | One ASX ticker code, e.g. BHP. One company per call — there is no batch form. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds useful behavioral context by stating it returns 'every capital raise on record,' implying completeness, and that it matches the paid page's data. This goes beyond the annotations without contradicting them.
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 zero waste. The first sentence front-loads the core purpose and data fields; the second provides a useful equivalence reference. No redundant or filler 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?
For a single-parameter, read-only tool with annotations and a fully described schema, the description is complete. It specifies the output fields, scope, and equivalence, so an agent can call it correctly without missing information. No output schema exists, but the description adequately explains the return content.
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% and the description adds no parameter-specific meaning beyond what the schema already provides (e.g., 'One ASX ticker code... no batch form'). Since the schema fully documents the only parameter, the baseline of 3 applies; the description does not enhance parameter understanding.
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 ('get') and resource ('raise history') with detailed fields (date, type, amount, issue price, shares issued, brokers, purpose) and scope (one ASX company). This clearly distinguishes it from sibling tools like get_cash_runway or get_dilution_snapshot, which target different financial 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 usage for retrieving raise history but does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. The sibling tools are not referenced. The only contextual note is 'Identical to the paid page's raise history,' which provides no comparative guidance. Usage is inferred 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.
Screen the ASX universe by dilution risk, cash cover, market cap industry or mining commodity and stage. Returns at most 20 rows — always the top of the requested ordering; there is no offset paging. A discovery tool, not an extract. Filters: q (name/ticker search), risk, cover, cap, industry, commodity, stage, suspended, sort, dir. Companies suspended from official quotation are EXCLUDED by default, the same as on the website; suspended_hidden in the response says how many this query withheld and suspended=include returns them.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Name or ticker search | |
| cap | No | nano | micro | small | mid | large | na | |
| dir | No | asc | desc | |
| risk | No | Very high | High | Moderate | Low | Minimal | Not rated | |
| sort | No | risk | dilution | cover | mktcap | raises | ticker | name | industry | itm | pending | expiry | short | |
| cover | No | <2q | 2-4q | 4+q | na | |
| stage | No | Stage of the company's most advanced project on that commodity: Exploration | Resource | Reserve | Scoping Study | Pre-Feasibility Study | Definitive Feasibility Study | FID | Production | Past Producer | |
| industry | No | GICS industry group, exact name as the site shows it, e.g. Materials, Energy, Software & Services, Pharmaceuticals, Biotechnology & Life Sciences | |
| commodity | No | Primary commodity of a mining or energy company, lower case, e.g. gold, copper, lithium, uranium, rare earths | |
| suspended | No | include — return companies suspended from official quotation, which are excluded by default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the readOnly/idempotent annotations by disclosing the hard 20-row cap, the absence of offset paging, that results are the top of the requested ordering, and the suspended-quotation exclusion policy. The `suspended_hidden` response field lets the agent detect and reason about withheld rows rather than silently under-reporting.
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?
Front-loaded with purpose, then behavior, then filters — the right order. Minor filler: "the same as on the website" and the trailing filter-name list duplicate what the schema already shows.
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 10 optional params, the description supplies the two things an agent most needs: the result cap and the suspension default. It omits the default sort/ordering and any note on result cost, which would round out a discovery 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 coverage is 100%, so the schema carries most parameter meaning. The description still adds real semantics for `suspended` (default exclusion, the `include` value, and its effect on the response) and for `q`; the remaining names are only restated.
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?
Specific verb plus resource ("Screen the ASX universe") with the exact filter dimensions enumerated. The line "A discovery tool, not an extract" cleanly separates it from the get_* siblings, which are single-entity lookups.
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 discovery-vs-extract framing tells the agent when this tool is the right first move rather than going to a detail tool. It stops short of naming a specific sibling or stating when to follow up with get_dilution_snapshot / get_cash_runway.
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.
screen2 fields changedInput schema / properties / commodityAdded value: +{
+ "description": "Primary commodity of a mining or energy company, lower case, e.g. gold, copper, lithium, uranium, rare earths",
+ "type": "string"
+}Input schema / properties / stageAdded value: +{
+ "description": "Stage of the company's most advanced project on that commodity: Exploration | Resource | Reserve | Scoping Study | Pre-Feasibility Study | Definitive Feasibility Study | FID | Production | Past Producer",
+ "type": "string"
+}get_cash_runwayget_dilution_snapshotget_issuance_timelineget_optionsget_raise_historyscreenSEC dilution data, live market data, and news for U.S. equities, with point-in-time as-of queries
SEC dilution data, live market data, and news for U.S. equities, with point-in-time as-of queries.
Free money calculators: option expiry risk, debt avalanche, cash runway, subscriptions, invoices.
Free US market data as tools: SEC filings, insiders, short interest, 13F, COT, Fed liquidity.
Add one secure layer between your agents and this server.
