Read-only impersonal market research: portfolio rankings, ticker scores, signals, daily briefs.
Scored across 17 tools
Most tools have clearly distinct purposes, but a few pairs (rankings vs signals, analyst_brief vs ticker_analyst) share overlapping concepts that could cause misselection. Descriptions are detailed and help clarify, but the boundaries are not perfectly crisp.
All tool names follow a consistent 'rayana_ai_<noun>' pattern in snake_case, using resource-oriented names like ticker_price and trends_detail. There are no mixed conventions or verb variants, making the naming highly predictable.
With 17 tools, the count is slightly above the typical well-scoped range, but the breadth of financial research data—briefs, portfolios, rankings, signals, trends, ticker details, and rotation—justifies each tool's existence. It feels appropriately sized for a comprehensive read-only research API.
The tool surface covers the primary research workflow: search, ticker detail, price history, articles, analyst reads, rankings, signals, consensus, trends, rotation, and portfolios. Minor gaps like historical analyst briefs or multi-date consensus snapshots prevent a perfect score but are not critical to the core domain.
The portfolio-analyst brief with its per-ticker views — the broadcast opinion layer, identical for every caller.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No |
| Name | Required | Description |
|---|---|---|
| brief | Yes | |
| views | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds valuable non-obvious behavior: the content is a broadcast opinion layer and is identical for every caller, implying no personalization or caller-specific state. This justifies a score above baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every clause adds content: the resource, the per-ticker scope, the opinion/broadcast nature, and the invariance across callers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple input (one optional date) and an output schema, so the description does not need to document return values. However, it omits the date parameter's meaning and provides no explicit action statement, leaving a moderate gap for an agent deciding how to invoke it.
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 input schema has one parameter, 'date', with 0% schema description coverage, yet the tool description makes no mention of date semantics (e.g., which date's brief is returned, what null means, whether historical dates are supported). The name 'date' is self-explanatory at a basic level, but the description adds no meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as a portfolio-analyst brief and adds distinguishing attributes (per-ticker views, broadcast opinion layer, identical for every caller), but it lacks a verb such as 'retrieves' or 'returns.' This makes the purpose somewhat implied rather than explicitly 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?
There is no guidance on when to use this tool versus its numerous siblings (e.g., rayana_ai_ticker_analyst, rayana_ai_consensus) and no exclusion criteria. 'Identical for every caller' hints at a non-personalized use case, but the description stops short of saying when this tool should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The public articles feed, newest first, when slug is omitted; one
published article's full body when slug is given.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | ||
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the description's job is lighter. It adds useful behavioral context: the feed is public, ordered newest first, and the slug mode returns a published article's full body. It does not clarify how limit/offset behave in single-article mode, but this is a minor gap.
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 compact sentence conveys both modes and the ordering behavior. Every clause earns its place, and the conditional structure is immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input surface, read-only annotations, and an output schema, the description is largely complete. The only notable omission is explicit semantics for limit/offset, especially in the slug mode, but the overall picture is sufficient 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 explains the behavior of slug well, but limit and offset are not described at all beyond their names and defaults. This is a significant gap for low-coverage schemas.
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 defines the tool's two modes: list feed when slug is omitted, retrieve full article body when slug is provided. It is specific about resource and behavior, but it does not explicitly distinguish itself from siblings like rayana_ai_ticker_articles, so it misses the top score.
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 conditional 'when slug is omitted... when slug is given' gives clear usage guidance for both modes. It does not mention alternatives or when not to use this tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-source consensus snapshots (insider trades, congressional trades,
earnings beats, dated catalysts, on-chain flows, 13F filings, AI
news-beneficiary reads). Omit source for every source at once, or
pass one of the slugs returned in a rankings/signals row's source list.
``limit`` caps rows per source. The sources are very unevenly sized —
institutional holdings runs to ~1700 rows where on-chain flows may have
two — so a source that comes back with exactly ``limit`` rows probably has
more, and narrowing with ``source`` and raising ``limit`` reads that one
layer deeply for far less context than raising ``limit`` across all
seven.| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| source | No |
| Name | Required | Description |
|---|---|---|
| onchain-flows | No | |
| event-calendar | No | |
| ai-news-analysis | No | |
| insider-activity | No | |
| earnings-surprise | No | |
| congressional-trading | No | |
| institutional-holdings | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only and open-world behavior, lowering the burden. The description adds valuable non-obvious behavior: sources are highly uneven in size, limit is per-source, and hitting exactly limit rows likely means more data exists. This goes well beyond the schema and does not contradict the 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?
The description is dense yet compact: two sentences cover purpose, parameter semantics, and a data-shape heuristic. Code-formatting for parameter names improves scanability, and every sentence adds value.
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 only two optional parameters, an output schema present, and read-only/open-world annotations, the description covers invocation choices and important size caveats. It could add an explicit use case or relationship to a specific sibling tool, but the essentials for selecting and calling this tool are present.
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, and it does. It explains that omitting source means all sources and that source accepts slugs from rankings/signals, and it defines limit as a per-source cap. It does not state the default limit value, but that is already present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as per-source consensus snapshots and enumerates seven distinct source types, making the tool's purpose recognizable. It lacks an explicit verb and does not contrast with sibling tools, but 'consensus' is a distinct resource among the rayana_ai_* siblings.
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 explicit invocation guidance: omit source to query all sources, or pass a slug returned by rankings/signals to target one source. It also provides a practical heuristic about uneven source sizes and how to read more deeply with less context, though it does not name sibling alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which lanes (daily/turtle/mr) currently have a batch available.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful context by enumerating the lane types and indicating a point-in-time availability check. However, it does not go beyond what the readOnlyHint and openWorldHint annotations already convey, and it does not describe empty-result behavior or staleness. This is adequate for a simple read-only status tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant restatement. Every word contributes to clarifying what the tool reports.
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 zero parameters, an empty input schema, read-only/open-world annotations, and an existing output schema, the description supplies the only needed context: which lanes are covered and what condition determines availability. Nothing needed to invoke the tool is missing.
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 has zero parameters, so the input schema already provides complete coverage. The description's mention of lane names is conceptually useful but not necessary for parameter understanding; baseline 4 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 clearly identifies the resource (lanes) and the condition (currently have a batch available), and it names the three lane types: daily, turtle, and mr. It lacks an explicit imperative verb like 'list' or 'return', which keeps it just short of a 5, but it is specific and not tautological.
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 intended use case is evident: call this tool when you need current batch availability for the daily, turtle, or mr lanes. It does not mention alternatives or exclusions, but with zero parameters and no obviously overlapping sibling tool, the selection context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The daily market brief: a generic engine-wide read with no
recommendations, descriptive only. Latest by default; pass
date (YYYY-MM-DD) for a specific day.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No |
| Name | Required | Description |
|---|---|---|
| brief | Yes | |
| notes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds valuable context beyond this: it explains the default behavior (latest), the scoping ('engine-wide'), and constraints ('no recommendations, descriptive only'). No contradiction with 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 concise sentences: the first defines the tool's purpose and scope, the second covers the parameter usage. No redundant words 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 tool is simple (one optional parameter) and has an output schema, so return values do not need explanation. The description covers the tool's nature, scope, default behavior, and parameter format—sufficient for an agent to invoke 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 only the parameter name 'date' with no description. The description compensates fully by explaining the format (YYYY-MM-DD), the default behavior (latest), and that it is optional. This gives the agent everything needed to pass the parameter correctly.
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 daily market brief with a specific scope: 'generic engine-wide read' that is 'descriptive only'. It distinguishes itself from siblings by emphasizing it has 'no recommendations', implying a contrast with analysis-focused tools like rayana_ai_analyst_brief.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly indicates when to use the tool ('Latest by default; pass date for a specific day') and implies when not (no recommendations, descriptive only). However, it does not explicitly name an alternative tool, leaving the agent to infer from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One model portfolio's full detail: holdings, overlay legs, event feed, NAV series, and windowed returns. Returns an error if the slug's tier (e.g. an Elite-only book) is above this key's own tier — a Pro key does not get Elite content just because it has MCP access.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
| Name | Required | Description |
|---|---|---|
| nav | No | |
| asof | No | |
| book | Yes | |
| slug | Yes | |
| events | No | |
| metrics | No | |
| overlay | No | |
| windows | No | |
| holdings | No | |
| delayed_to | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds meaningful behavioral context beyond that: it explains the tier-based authorization behavior and the error case where a Pro key cannot access Elite content. This is valuable information an agent needs before calling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence front-loads the tool's function and contents, and the second concisely covers the important authorization/error behavior.
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 one-parameter, read-only tool with an output schema, the description covers purpose, contents, and a key error condition. It is slightly incomplete in not pointing to a sibling tool for discovering slugs, but this does not prevent correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a bare 'slug' string with 0% description coverage. The description compensates by tying the slug to a model portfolio and explaining that the slug carries a tier affecting access. It does not specify slug format or how to find valid slugs, but for a single conventional identifier this is a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'One model portfolio's full detail' and enumerates specific contents: holdings, overlay legs, event feed, NAV series, and windowed returns. This clearly identifies a detail/retrieval tool for a single portfolio and distinguishes it from siblings like rayana_ai_portfolios.
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 singular framing and requirement of a slug make it clear this tool is for retrieving full detail on one specific portfolio, not for listing portfolios. The tier/error warning also gives useful selection context, though it does not explicitly name alternative tools such as rayana_ai_portfolios for listing available slugs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The full shelf of Rayana AI's broadcast model portfolios as merchandising cards, with each card's tier/openable/delayed flags.
| Name | Required | Description | Default |
|---|---|---|---|
| include_retired | No |
| Name | Required | Description |
|---|---|---|
| tier | Yes | |
| count | Yes | |
| portfolios | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, covering the safety profile. The description adds that results are merchandising cards with tier/openable/delayed flags, but does not disclose any other behavioral traits such as pagination, filtering behavior, or auth needs. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It names the resource, output form, and key card attributes compactly, and every word contributes to the tool's meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with an output schema and one optional boolean parameter, the description is nearly sufficient. It misses only an explicit mention of include_retired and a pointer to rayana_ai_portfolio for singular access.
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 never mentions include_retired or explains how it affects the returned shelf. The schema's title and default value carry the only meaning; the description adds no parameter-level guidance and may even imply all portfolios are always included.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource ('Rayana AI's broadcast model portfolios'), the scope ('full shelf'), and the output form ('merchandising cards' with tier/openable/delayed flags). It distinguishes itself from the singular sibling rayana_ai_portfolio through the plural 'portfolios', but lacks an explicit verb like 'list' or 'retrieve'.
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 'full shelf' implies this is the list-all tool compared to the singular rayana_ai_portfolio, but no explicit when-to-use guidance or alternative tool names are given. Usage context is only implied, not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest ranked candidate batch for a lane: daily (the main research lane), turtle (breakout system), or mr (mean-reversion). Rows come back in rank order, best first, so the default page is the top of the batch.
``total`` in the response is the batch size; when it exceeds ``count``,
page with ``offset``. ``include_assessment`` adds each row's technical
blob (pattern and cluster validation, volume profile) — it triples the
response, so prefer ``rayana_ai_ticker`` for one name's detail and leave
this off when scanning.| Name | Required | Description | Default |
|---|---|---|---|
| lane | No | daily | |
| limit | No | ||
| offset | No | ||
| include_assessment | No |
| Name | Required | Description |
|---|---|---|
| lane | Yes | |
| count | Yes | |
| total | No | |
| asof_hint | No | |
| truncated | No | |
| candidates | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/openWorldHint annotations, it discloses ordering (rank order, best first), pagination semantics (total vs count), and the performance cost of include_assessment. These are meaningful behavioral traits not visible in the schema or 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?
The description is compact, front-loaded with the core purpose, and every sentence adds operational value. No filler or redundant restatement 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?
Given an output schema exists and annotations cover read-only/open-world behavior, the description supplies the missing operational context: ranking order, pagination trigger, and when to use the expensive option. An agent has enough to call 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 description coverage is 0%, but the description compensates well by explaining lane values, offset-based paging, and include_assessment's effect. It does not explicitly define limit, though the total/count/offset explanation implies it, so a small gap remains.
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: returns the latest ranked candidate batch for a named lane, and enumerates the three valid lanes. It clearly differentiates this tool from sibling tools like rayana_ai_ticker by framing this as batch rankings rather than single-name detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit guidance on when to page via offset, when to leave include_assessment off, and when to prefer rayana_ai_ticker for single-name detail. This is actionable routing advice that helps an agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cluster-rotation layer. summary: latest per-cluster RRG
quadrant/rank rows with deltas, plus the most recent quadrant-crossing
events (days controls the window both are computed over).
laggards: members trailing a firing cluster's leader. discovered:
unsupervised cluster-discovery cohorts the structural taxonomy misses.
members: structural cluster membership.
On ``summary``, two blocks are trimmed because together they are 80% of
the response while answering a narrower question than the rows do.
``include_trajectory`` adds each cluster's full rank series — a chart
payload, off by default. ``events`` returns the newest 25 crossings; if
exactly 25 come back there are probably older ones, and a wider ``days``
is not what returns them.| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| view | No | summary | |
| include_trajectory | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint) provide a baseline, but the description adds rich behavioral detail: trimming two blocks because they are 80% of the response, include_trajectory being off by default and adding a chart payload, and events returning the newest 25 crossings with a caveat about exactly 25 indicating older ones. This goes well beyond annotations and paints a clear picture of what the tool does internally.
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 paragraph without clear sectioning. It front-loads the purpose but quickly dives into details about trimming, events, and trajectory without a logical order. Multiple ideas (views, trimming, events limit) are packed in, making it longer than necessary and harder to scan. It's not elegantly structured, though it conveys needed info.
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 an output schema present, return values are covered, but the description still has gaps. It explains summary and include_trajectory well, but laggards/discovered are only one-liners. The 'events' mention is ambiguous (not in the view enum), and it doesn't clarify whether days applies to all views. For a tool with 3 parameters and 4 distinguished views, the description is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It does: view is explained with one-liners for each enum value, include_trajectory is described, and days is tied to the summary window. However, it introduces an 'events' concept that isn't a parameter and explains only summary's window control, leaving laggards/discovered/members' dependence on days ambiguous. This adds value but is incomplete and slightly confusing.
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 purpose: 'Cluster-rotation layer' and enumerates distinct views (summary, laggards, discovered, members) with brief roles. Clearly describes what it does, but does not explicitly differentiate from sibling tools such as rayana_ai_rankings or rayana_ai_trends, which might overlap. The name and domain strongly imply the purpose but without naming alternatives, 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?
No explicit guidance on when to choose this tool over alternatives. It describes internal behavior and options but never states a typical use case, prerequisite, or exclusion. For instance, it doesn't say 'use this when you need cluster rotation data' or contrast with siblings. The usage context is only implied by the tool's name and domain vocabulary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve free text (ticker or company name) to known Rayana AI symbols, best match first. Pure resolution — never accrues signal.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds useful behavior beyond those: results are ordered best match first, and the operation never accrues signal, implying no state or side effects. There is no contradiction.
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 short sentences with the core action front-loaded. The 'pure resolution' clause earns its place by preventing misuse, and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema, annotations, and only two parameters, the description covers the essential semantics well. The main gaps are the meaning of limit and explicit routing among the many sibling tools, but these are minor for a simple lookup 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?
With 0% schema description coverage, the description partially compensates by explaining that q accepts a ticker or company name as free text. However, the limit parameter is left undocumented beyond its schema default, so parameter semantics are incomplete.
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: resolve free text (ticker or company name) to known Rayana AI symbols, with best match first. It also distinguishes itself from signal-producing siblings by adding 'Pure resolution — never accrues signal.'
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 makes the use case clear: use this tool when you have a ticker or company name and need the canonical symbol. It does not name alternatives explicitly, but the 'never accrues signal' clause warns against using it for signal retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest aggregator-consensus batch for one asset lane: which tickers cleared the signal pipeline, blended agg_score, confirming source count.
| Name | Required | Description | Default |
|---|---|---|---|
| lane | No | equity | |
| limit | No |
| Name | Required | Description |
|---|---|---|
| lane | Yes | |
| count | Yes | |
| signals | Yes | |
| truncated | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful context about the output content and lane scoping, but does not disclose additional behavior such as rate limits, pagination, or the dynamic nature of 'latest' beyond what openWorldHint 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?
A single compact sentence front-loads the core purpose and quickly enumerates the key output fields. There is no filler, and every clause adds information about what the tool produces.
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, combined with the input schema's enum for lane and the presence of an output schema, is nearly complete for a read-only aggregator tool. It would benefit from a brief note about 'limit,' but defaults and the output schema mitigate the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It partially explains 'lane' through 'one asset lane,' but it does not explain 'limit' at all, leaving whether it caps ticker count, score count, or batch size ambiguous. The description does not fully compensate for the lack of parameter documentation.
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 what the tool returns: the latest aggregator-consensus batch for one asset lane, including ticks that cleared the pipeline, blended agg_score, and confirming source count. It does not explicitly contrast itself with siblings like rayana_ai_consensus or rayana_ai_rankings, so it stops short of the 5 bar for explicit sibling differentiation.
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 want consensus signal data for a single asset lane. But it gives no explicit guidance about when to prefer this over rayana_ai_consensus, rayana_ai_rankings, or similar siblings, and offers no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full per-ticker research view: score, lane membership, per-source signals, virality, consensus, cluster-rotation position, forward returns.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
| Name | Required | Description |
|---|---|---|
| score | No | |
| detail | No | |
| ticker | Yes | |
| truncated | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint and openWorldHint, so the description is not required to restate that the tool is safe and read-only. The description adds the contents of the view but no operational traits such as data freshness, pagination, or error behavior. It does not contradict the 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?
The description is a single compact sentence with the main idea front-loaded ('Full per-ticker research view') followed by a precise colon-separated list of contents. There is no filler, repetition, or unnecessary context.
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 read-only tool with an output schema and safety annotations, the description covers the main content. The main gap is contextual routing: with 16 sibling tools, the description does not say how this aggregate view compares to more targeted ticker tools, leaving selection partly to inference.
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 one required parameter. 'Per-ticker' partially indicates that symbol is a ticker symbol, but that mostly restates the tool name and does not specify expected format, casing, or examples. The description provides only minimal added meaning beyond the schema's bare 'Symbol' field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific resource—the per-ticker research view—and lists its contents: score, lane membership, per-source signals, virality, consensus, cluster-rotation position, and forward returns. This makes it recognizable as an aggregate research snapshot and distinguishable from ticker-price, ticker-articles, and ticker-analyst siblings. It does not explicitly name those siblings, so it misses the top score by a small margin.
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 'Full per-ticker research view' gives a clear implied usage: use this tool when you need comprehensive research data for one symbol. However, there is no explicit when-to-use or when-not-to-use guidance, and no mention of the many sibling ticker-scoped tools that might be more appropriate for narrower questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Today's cached AI ticker-analyst read (lean, conviction, thesis, evidence for/against, invalidation condition). Never triggers a new model call; 404s if nothing was generated today for this ticker.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
| Name | Required | Description |
|---|---|---|
| lean | No | |
| model | No | |
| cached | No | |
| thesis | No | |
| ticker | Yes | |
| cost_usd | No | |
| conviction | No | |
| created_at | No | |
| evidence_for | No | |
| invalidation | No | |
| analysis_date | Yes | |
| evidence_against | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true. The description adds genuine value beyond them by disclosing the 404-on-missing-data failure mode and explicitly confirming no new model call is triggered, which is behavioral context an agent needs to handle invocation correctly. Nothing contradicts the 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 tight sentences with no filler: the first front-loads the resource and its content fields, the second packs the behavioral constraints (no model call, 404 behavior). Every clause 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 single-parameter, read-only cached lookup with an output schema and safety annotations, the description covers what is returned, its cache status, and its failure mode, which is nearly complete. The only notable gap is explicit differentiation from the closely named rayana_ai_analyst_brief sibling, but the tool's low complexity keeps this minor.
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 undocumented `symbol` parameter. It only links the parameter to 'this ticker' contextually, without stating format, valid values, or an example (e.g., 'AAPL'). For a tool at 0% coverage, this minimal linkage is insufficient compensation.
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 resource (today's cached AI ticker-analyst read), the time window, and enumerates the exact content fields (lean, conviction, thesis, evidence for/against, invalidation condition). The 'cached' and 'never triggers a new model call' qualifiers sharply distinguish it from generating siblings like rayana_ai_analyst_brief.
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 cache behavior and 404-on-absence imply when results will be available, but the description never explicitly says when to choose this tool over siblings such as rayana_ai_analyst_brief or rayana_ai_signals. No alternative is named and no when-not-to-use exclusion is stated; usage context is implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One ticker's published article history, newest first.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| limit | No | |
| total | No | |
| offset | No | |
| articles | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world behavior. The description adds useful behavioral context by stating the result is limited to published articles and sorted newest first, which is beyond what annotations provide. It does not mention pagination or limits, but for a simple read-only list this is acceptable.
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 eight words and every word earns its place, front-loading the core scope ('one ticker's published article history') and ending with the useful ordering detail. 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?
For a one-parameter read-only tool with an output schema and read-only annotations, this description covers what the tool returns and in what order. It is slightly less complete on pagination or volume behavior and on explicit sibling differentiation, but nothing critical is missing.
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 has zero description coverage for the required symbol parameter, and the description barely compensates: it only implies that symbol refers to a ticker. It provides no format, examples, or constraints beyond what the schema's 'Symbol' title already suggests.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the exact resource: a single ticker's published article history, ordered newest first. It is clear enough to distinguish this from broader article tools like rayana_ai_articles, but it is a noun phrase with no explicit action verb and does not name a sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'one ticker's' implies this tool is for retrieving article history for a specific symbol. However, it does not explicitly say when not to use it or point to rayana_ai_articles as the broader alternative, so the usage decision is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Daily close-price history for one ticker over the given period.
Long periods are evenly sampled down to ``max_points`` bars rather than
cut short, so the series still spans the whole period — ``5Y`` and ``MAX``
return the shape of the history, not its last year. ``last_close``,
``change_pct`` and the ``range_low``/``range_high`` extremes are computed
over every bar regardless of sampling.| Name | Required | Description | Default |
|---|---|---|---|
| period | No | 1Y | |
| symbol | Yes | ||
| max_points | No |
| Name | Required | Description |
|---|---|---|
| period | Yes | |
| points | Yes | |
| ticker | Yes | |
| range_low | No | |
| change_pct | No | |
| last_close | No | |
| range_high | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant non-obvious behavior: long periods are evenly sampled down to max_points rather than cut short, 5Y/MAX return the full shape, and metrics like last_close/change_pct are computed over every bar regardless of sampling. This goes well beyond the readOnlyHint and openWorldHint annotations and is consistent with 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?
The description is compact and front-loaded: the core purpose is stated in the first sentence, and the second sentence justifies the sampling behavior without excess prose. Every sentence adds 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?
Given the read-only annotations, an output schema, and only one required parameter, the description covers the necessary call semantics, parameter meaning, and hidden sampling behavior. Nothing material is missing for an agent to invoke this 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 carry the meaning. It does explain max_points and period behavior ('Long periods are evenly sampled down to max_points bars') and references period values like 5Y and MAX. Symbol is self-explanatory, and the enum/defaults are already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource and action: 'Daily close-price history for one ticker over the given period.' It is specific enough to distinguish from broker/analyst or article siblings, though it does not name a sibling or explicitly contrast itself with rayana_ai_ticker.
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 prefer this tool over siblings or when not to use it. The description explains behavior but never states conditions like 'use this for historical price series' or 'for current quotes, use X instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The attention leaderboard: latest virality snapshot ranked by VScore, with the full intensity/breadth/slope/vramp decomposition.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
| asof | No | |
| count | Yes | |
| leaders | Yes | |
| truncated | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context by saying this is a latest snapshot and specifying the VScore decomposition, which tells the agent what shape of result to expect beyond the bare tool name. It does not document pagination or data freshness, but the statement is adequate for a simple read-only leaderboard.
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 dense, front-loaded sentence with no filler. The core concept ('attention leaderboard') appears first, followed by the ranking basis and metric decomposition, so an agent gets the essential meaning in a single glance.
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 one optional parameter, read-only/open-world annotations, and an output schema, the description is largely complete: it conveys what is ranked, by what metric, and in what granularity. The only gap is that it does not differentiate itself from closely named siblings like rayana_ai_rankings or rayana_ai_trends_detail, which could cause a less careful agent to pick the wrong tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the optional 'limit' parameter at all. While 'limit' with a default of 40 is reasonably self-explanatory, the rubric requires the description to compensate when schema coverage is low; it does not.
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 ranked virality leaderboard resource and names the ranking metric (VScore) plus its decomposition into intensity/breadth/slope/vramp. It stops short of an explicit verb like 'get' or a direct point of contrast with siblings such as rayana_ai_rankings or rayana_ai_trends_detail, but the noun-phrase framing is still specific and useful.
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 'latest virality snapshot' implies the tool is for current attention rankings, but there is no explicit when-to-use/when-not-to-use guidance and no alternative tools are named. Given the large sibling set, an agent would benefit from a note such as 'use trends_detail for a single trend's breakdown,' but the context is at least implicitly conveyed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The attention layer's raw texture. sources: per-source reach today.
heat: per-(ticker, source) attention contributions. search:
rising/breakout consumer search queries. video: rising video-view
velocity. limit applies to search/video only; omit it to use that
view's own default.
| Name | Required | Description | Default |
|---|---|---|---|
| view | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds behavioral value by clarifying what each view returns and by specifying that limit is ignored for sources/heat and that omitting it uses the view's default, which goes beyond the raw schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized, with each subview given a short definition and a dedicated note for limit. The opening metaphor 'The attention layer's raw texture' is somewhat vague, but it does not waste words and the parameter-related content is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with only two parameters, an output schema, and one enum, the description covers the essential calling semantics: what each view means and how limit behaves. The main missing piece is an explicit statement of when to use this tool versus the sibling rayana_ai_trends, but this is not critical for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden of explaining the parameters. It defines every enum value of view (sources, heat, search, video) and clarifies the behavior of limit, including its view-specific scope and default behavior. This is strong compensation, though it does not specify limit's numeric range or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as exposing the attention layer's raw texture and enumerates four concrete subviews (sources, heat, search, video), each with a specific meaning. It is clear about the resource but lacks an explicit verb like 'retrieve' or 'return', and it does not differentiate itself from the sibling rayana_ai_trends tool.
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 useful per-view context and explains that limit applies only to search/video, which is a form of usage guidance. However, it never says when to choose this tool over the sibling rayana_ai_trends or any alternative, leaving the selection largely implied by the name 'detail'.
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.
rayana_ai_analyst_briefrayana_ai_articlesrayana_ai_consensusrayana_ai_lanesrayana_ai_market_briefrayana_ai_portfoliorayana_ai_portfoliosrayana_ai_rankingsrayana_ai_rotationrayana_ai_searchrayana_ai_signalsrayana_ai_tickerrayana_ai_ticker_analystrayana_ai_ticker_articlesrayana_ai_ticker_pricerayana_ai_trendsrayana_ai_trends_detailRead-only public-company financials, KPIs, benchmarks, filings, and insider activity.
Read-only value-investing fund, holdings, financial, options, and insider research.
Portfolio analytics + US-equity market research for AI clients. ChatGPT deep-research compat.
Read-only paper risk evidence and policy-gated committed event research. No real orders.
Add one secure layer between your agents and this server.
