The market's attention, measured, with receipts.
Scored across 4 tools
asset and board are clearly distinct (single asset vs all assets), and methodology is unique. However, receipts partially overlaps with asset's 'past events with receipts' since both can return event/receipt data for a given symbol, though the descriptions clarify scope.
All tool names are single lowercase nouns (asset, board, methodology, receipts) with no mixing of verb styles or casing. This is fully consistent and predictable for a read-only data API.
The 4 tools map directly to the API's four read-only endpoints, each covering a distinct slice (per-asset detail, global board, docs, resolved events). The count is well-scoped with no redundant or missing companion tools.
The read-only public domain (board snapshot, asset detail, methodology, receipts) is fully covered; no create/update/delete operations are needed. Optional symbol filtering on receipts and per-asset receipts cover the event retrieval paths.
One asset in depth: latest snapshot, 7d heat series, open event, past events with receipts. Same data as GET /api/asset/{symbol}.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Ticker symbol, e.g. BTC or GME |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the data returned (snapshot, heat series, events with receipts) and implies read-only behavior via the GET endpoint reference, but it omits permissions, rate limits, and side-effect details. This is moderate disclosure without full annotation coverage.
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 purpose and return contents, followed by an endpoint comparison. Every sentence earns its place with 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?
For a simple one-parameter retrieval tool with no output schema, the description sufficiently explains what data is returned and provides an API reference. It leaves a minor gap in usage guidance versus siblings, but otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single required parameter 'symbol' fully documented in the schema (ticker symbol, e.g. BTC or GME). The description adds no parameter semantics beyond the schema, so the baseline score of 3 applies.
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 the tool returns one asset's detailed data: latest snapshot, 7d heat series, open event, and past events with receipts. It distinguishes itself from siblings like board and methodology by focusing on a single asset, and references the concrete endpoint GET /api/asset/{symbol}. It lacks an explicit verb, but the resource and scope are 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 explicit guidance on when to use this tool versus siblings such as board, methodology, or receipts. The phrase 'One asset in depth' implies a single-asset focus, but it does not state when that is preferable to alternatives or any preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current Tickerz Heat board: all tracked assets with price, 24h move, and Heat (0-100), plus updated_at. Same data as GET /api/board.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It implies a read-only snapshot by describing 'Current' data and likening it to a GET endpoint, and it discloses the returned fields, which is useful. It does not state freshness guarantees (beyond updated_at), rate limits, or whether the listing is paginated, which are the remaining behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero filler. The resource and its contents are front-loaded before the secondary REST-equivalence note, so an agent gets the essential information immediately.
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 parameters, no annotations, and no output schema, the description must describe the payload itself, and it does so by naming the exact fields returned. That covers the main need for a zero-arg read tool. Minor gaps remain around data freshness and whether the result is bounded (top-N vs all assets is stated, so this is largely covered).
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 tool takes zero parameters, so there are no parameter semantics to explain; a baseline of 4 applies. The description correctly reads as a parameterless snapshot endpoint rather than implying hidden arguments.
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 resource (the 'Current Tickerz Heat board') and enumerates exactly what it returns: all tracked assets with price, 24h move, Heat (0-100) and updated_at. An agent knows precisely what this tool yields. It does not, however, explicitly differentiate itself from siblings like asset or methodology, 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?
There is no statement of when to reach for this tool versus the sibling set (asset, methodology, receipts). The 'Same data as GET /api/board' note is a REST-equivalence fact, not usage guidance or an exclusion. The agent must infer usage from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public Sigma-1 Heat methodology as text (same disclosure as https://tickerz.com/methodology). No proprietary parameters.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that the output is text and the public disclosure mirrors a specific URL, and 'No proprietary parameters' signals there is nothing hidden or configurable. It does not address auth, rate limits, or return format beyond 'text', so it is partial.
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 front-loaded sentence that states what the tool returns and its scope, with the URL parenthetical earning its place by pinning the exact disclosure. No waste.
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 zero-parameter, text-returning tool with no output schema, the description covers what is returned and its public nature. It could briefly note the text format/length expectation, but it is nearly sufficient.
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 tool takes zero parameters, which sets the baseline at 4. The description reinforces this with 'No proprietary parameters', so nothing is left ambiguous about 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?
Names a specific resource ('Sigma-1 Heat methodology') and its form ('as text'), so an agent knows this returns documentation rather than data. It is reasonably distinguishable from siblings like asset/board/receipts, though it does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance, no exclusions, and no mention of the sibling tools. The agent must infer that this is the go-to for explaining the methodology behind the other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolved Heat events with 24h / 7d / 30d forward returns. Optional symbol filter. Same store as GET /api/receipts.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 1 to 100, default 30 | |
| symbol | No | Optional ticker to filter, e.g. BTC |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral load. It usefully discloses the returned data shape (three forward-return horizons) and maps to an underlying REST endpoint, implying a read-only lookup, but it never states safety, ordering, freshness, or default result count behavior beyond what the schema implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, front-loaded sentences with no filler; the payload contents come first and the constraining details follow. The endpoint mapping sentence is compact and earns its place, though the fragment style is a bit clipped.
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 two-optional-parameter read tool with no output schema, the description adequately conveys what comes back and that filtering is optional. It omits return ordering, time window definitions for the returns, and any error or empty-result behavior, leaving an agent guessing about result 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 100%, so both parameters are already documented with bounds and defaults. The description only restates that symbol filtering is optional, adding no format or semantics beyond the schema; baseline 3 applies.
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 resource (resolved Heat events) and the payload (24h/7d/30d forward returns), which is far more informative than the opaque tool name 'receipts' alone. It does not explicitly contrast itself with the siblings (asset, board, methodology), but the resolved-event/returns scope is distinct enough to route an agent.
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 only usage signal is that the symbol filter is optional and that limit bounds exist implicitly. There is no guidance on when to call this versus board or methodology, no prerequisites, and no statement of whether results are paginated or ordered.
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.
assetboardmethodologyreceipts
