Agentcity Robinhood Chain Research

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full disclosure burden. It usefully declares 'Read-only' and names the data sources (lightweight GMGN fundamentals and security data), but says nothing about rate limits, auth, latency, or failure behavior for one or more invalid addresses.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One front-loaded sentence with zero filler; the read-only nature, the resource, and the cardinality all land 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?

For a no-annotation, single-parameter, no-output-schema tool the description is adequate but thin: it does not indicate what the comparison output contains beyond a vague 'fundamentals and security data' or how results are ordered relative to the input addresses.

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% for the single 'addresses' parameter, but the schema itself enforces the 0x-address pattern and the 2–5 item bounds, which the description merely restates. No additional meaning (e.g., ordering, duplicate handling) is supplied.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (compare), resource (Robinhood Chain token contracts), and scope (2–5 contracts) in one clause. It clearly differentiates from siblings like agentcity_research_robinhood_token, which handles a single token rather than a comparative set.

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 2–5 cardinality constraint implies a batch/comparative scenario, but the description never says when to prefer this over research_robinhood_token or search_robinhood_token, nor any exclusions or prerequisites. Usage is inferable but not stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry the full behavioral burden. It does disclose that the operation is read-only, which is the single most important safety fact, but says nothing about result ordering, pagination via limit, or what 'graduated/completed' means operationally.

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, zero filler. The scope constraint and the default behavior are front-loaded before the optional narrowing parameter, which is the right order for an agent scanning for a routing decision.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a four-parameter, no-annotation, no-output-schema tool, the description covers the two semantically richest parameters but omits limit/pagination behavior and liquidity filtering. An agent can invoke it, but the boundary against the screening and trending siblings remains unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 25%, so the description should compensate more than it does. It usefully decodes the stage values ('newly created, near-completion, graduated') and the launchpads scoping, but leaves limit and minLiquidityUsd entirely unaddressed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('discovery') and resource ('Robinhood Chain launchpad tokens'), and enumerates the three lifecycle stages it covers, which maps directly onto the stage enum. It is distinguishable from generic siblings like trending or signals, but it never names a sibling tool to contrast against, 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?

It gives the default scope ('chain-wide by default') and the narrowing condition ('pass launchpads to restrict to Pons or Trench'), which is useful routing information. However, it never says when to prefer this over screen_robinhood_launchpads or trending, so the alternative-selection guidance is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry the behavioral load, and it does disclose read-only status and that the output is a deterministic score, not a trading directive. It omits data freshness, rate limits, auth needs, and what 'multi-source' concretely covers beyond GMGN.

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 resource and scope, and no filler. The 'never a trading directive' clause earns its place by setting expectations for the score output.

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 no-annotation, no-output-schema tool, the description covers what it does and roughly what it returns, but leaves the parameters unexplained and the return payload's shape unspecified.

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% and neither of the two parameters is explained. The description never says that 'address' identifies the token nor what 'holderLimit' controls (holder sample size), so it fails to compensate for the undocumented 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?

States a specific verb and resource: multi-source GMGN due diligence on a Robinhood Chain token. It is clearly a research/aggregation tool, though it never explicitly contrasts itself with close siblings like agentcity_robinhood_signals or agentcity_robinhood_smart_money.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use, prerequisites, or alternative routing is given. The agent can infer it is for researching a single token, but nothing tells it when to prefer this over search, signals, or smart_money.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden. It does disclose 'Read-only' and that smart-money data is conditional, which is useful. It says nothing about rate limits, latency, auth requirements, or that limits are capped (schema maxima of 80/100), leaving meaningful 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?

A single front-loaded sentence with no filler; the read-only nature and the aggregation scope lead. Slightly terse for a 3-param tool, but 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?

No output schema, no annotations, and 3 undocumented params. The description conveys the shape of the return (a combined brief) well enough to call it, but omits default behavior and any indication of how the aggregated payload is structured.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It conceptually maps to all three params (launches → launchLimit, trending → trendingLimit, optional smart-money → includeSmartMoney), which is real value, but it never names the parameters or mentions their defaults (30/30/false) or ranges.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (read-only briefing) and enumerates the exact content it aggregates: new Robinhood launches, 24-hour trending, and optional smart-money trades. This distinguishes it in substance from siblings like list_robinhood_launches and robinhood_trending, though it never names them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use or when-not-to-use guidance is given. The description tells you what the brief contains but not why an agent would pick it over the individual list_robinhood_launches / robinhood_trending / robinhood_smart_money tools, nor what the tradeoff is (e.g., one round-trip vs. targeted calls).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden; it does disclose 'read-only' and names the upstream data source (GMGN), which is genuine safety/context value. However, it says nothing about return shape, rate limits, freshness/latency of signals, or whether results are paginated — significant gaps for an annotation-free 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?

A single sentence, correctly front-loaded with the read-only nature and the resource, with the optional market-cap scoping placed last. Nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No annotations, no output schema, and three parameters at zero schema coverage, one of which (signalTypes integer codes) is entirely unexplained. For a tool whose primary input is an opaque numeric enum range, the description does not supply enough for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description only gestures at the market-cap bounds, adding no format or semantics beyond the parameter names. The signalTypes parameter is an array of integers bounded 1–21 with no mapping to meanings anywhere, so an agent cannot construct a valid call — this is the most serious documentation hole.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — reading GMGN market signals on Robinhood Chain — and gives concrete examples (smart-money buys, volume spikes). It does not distinguish itself from siblings like agentcity_robinhood_smart_money, so an agent cannot tell from the description alone why it should pick this over that one.

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 when-to-use instruction, no exclusions, and no named alternative despite an obvious overlapping sibling (agentcity_robinhood_smart_money). The agent must infer usage entirely from the examples of signal content.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full disclosure burden. It usefully flags 'Read-only' and 'recent', but says nothing about recency window, result ordering, pagination, rate limits, or auth requirements for a feed 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?

A single front-loaded sentence with no filler. The scope constraint (read-only) and the data source lead the sentence, which is exactly what an agent needs first.

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 feed with three optional parameters and no output schema, the description covers the essentials of what the tool returns conceptually. However, with no output schema it should still hint at the shape of returned trade records and the meaning of 'recent'.

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 clarifies the 'source' concept (smart-money vs KOL wallets) but is silent on the 'side' buy/sell filter and the 'limit' cap, leaving two of three parameters unaddressed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: a read-only feed of recent trades, scoped to GMGN-tagged smart-money/KOL wallets. The purpose is clear and distinct from token/launch/signal siblings, but it never names a sibling to differentiate itself explicitly.

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 when-to-use, when-not-to-use, or alternative guidance. The agent must infer usage purely from the noun phrase 'recent trades by smart-money or KOL wallets' with no routing help against the other nine Robinhood tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are supplied, so the description carries the entire behavioral burden, and it only discloses 'Read-only'. It says nothing about how much history is returned, per-resolution limits, pagination, rate limits, or auth requirements for a time-series endpoint where history depth is the central behavioral question.

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 with a semicolon-appended purpose clause; every word carries information and nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description should specify the returned candle fields and the available history window or limits. Naming 'OHLCV/K-line' partially covers the return shape, but the missing resolution semantics and depth limits leave gaps an agent would hit at call time.

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% for both parameters. The description only obliquely implies that 'address' identifies a token; it never explains the 0x address format, nor does it mention that 'resolution' selects candle interval, that seven intervals exist, or that the default is 5m.

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?

It names a specific verb and resource (read-only OHLCV/K-line history) scoped to a Robinhood Chain token, which is materially more precise than the sibling names like signals or trending. It does not, however, explicitly contrast itself with or route to any sibling such as agentcity_research_robinhood_token, so it lands at a clear-but-undifferentiated 4.

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 clause 'useful to distinguish fresh activity from sustained momentum' implies an analytic context for using candle data, which is real but indirect guidance. There is no explicit when-to-use rule, no when-not-to-use, and no named alternative among the nine sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral burden. It discloses that the operation is read-only and sourced from GMGN, but does not explain rate limits, authentication needs, data freshness, pagination, or what 'trending' means operationally.

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 wasted words. However, its extreme brevity leaves critical usage and parameter context unstated.

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 two optional parameters, no parameter descriptions, no output schema, and no annotations, the description is too thin. It identifies the domain and read-only nature but omits what the result contains and how the interval and limit affect 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?

Schema description coverage is 0% for two parameters, limit and interval, and the description does not mention either parameter. It does not explain supported intervals, the meaning of the limit, or defaults, so it fails to compensate for the undocumented 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 states a clear verb-like purpose: read-only trending tokens on Robinhood Chain from GMGN. It identifies the resource and source well, but does not differentiate itself from related siblings like agentcity_robinhood_signals or agentcity_robinhood_smart_money.

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 guidance on when to use this tool versus alternatives. It only labels the operation as read-only, leaving the agent to infer that it should be chosen for trending-token discovery.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden, and it does disclose the crucial safety property ('read-only', 'never executes a trade') plus the data source ('GMGN server-side filters'). However it says nothing about rate limits, result shape, pagination, or how the 'safe/smart-money/strict' profiles affect behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the core purpose and scope, with the safety disclaimer last. No wasted words, though the brevity leaves the tool under-explained rather than over-explained.

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 seven-parameter filtering tool with zero annotations, no output schema, and near-zero schema documentation, the description is far too thin. An agent still cannot tell what the profiles mean, what fields are returned, or how results are ordered or paged.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 14% (only 'launchpads' is documented), so the description is expected to compensate, yet it mentions none of the seven parameters. Terms like 'quality screen' and 'server-side filters' gesture at filtering but give no meaning for maxRugRatio, minLiquidityUsd, minSmartMoneyCount, stage, or profile.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('screen') and resource (Robinhood Chain launchpads) with a qualifier ('quality'), which distinguishes it from sibling listers like agentcity_list_robinhood_launches. It does not explicitly name which sibling to prefer, but the screening intent is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no when-to-use guidance relative to the nine sibling tools, and no exclusions or prerequisites. Only an implicit signal ('quality screen', 'GMGN server-side filters') hints at its role, which is not enough to route an agent between this and list/search/trending alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry behavioral disclosure. It self-declares "read-only," which is the most important trait, but says nothing about result caps, pagination, rate limits, or auth requirements for a search that can return multiple candidates.

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, front-loaded with the capability followed by the usage caveat. No filler and nothing repeated from structured fields.

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-param search with no output schema and no annotations, the description covers purpose and input forms adequately. A brief note on result handling (multiple candidates returned) is the only meaningful 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 the single undocumented `query` param. It does so by enumerating accepted input forms (name, symbol, contract address), which is meaningful guidance the schema lacks, though it omits length/format constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (search) plus resource (Robinhood Chain tokens) and the accepted key types (name, symbol, contract address). It differentiates implicitly from research/deep-dive siblings by framing this as candidate resolution, though it does not name any sibling explicitly.

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?

"Use it to resolve a symbol to candidate contracts; symbols are not unique" gives a clear usage context and a caveat that shapes expectations. It stops short of naming an alternative tool for when a single resolved token is needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.