Alpha Bazaar Arena

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is partly covered. The description adds genuinely new behavioral context the annotations cannot express: the two hard failure windows (post-entry-price and the 5-minute pre-open blackout). It does not mention auth requirements or whether the deletion is irreversible, so it falls just short of a 5.

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 sentence carries the action, the precondition, the example, the two exclusion windows, and the alternative tool. The operative constraint is front-loaded and 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 one-parameter destructive tool with an output schema absent but unnecessary, the description covers the decisive question of when the call will fail. Only minor gaps remain, such as whether the cancellation is permanent or what state the signal is left in.

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

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

Schema description coverage is 100% and the single signal_id parameter is already documented with its source ('from publish_signal or list_my_signals'). The description adds no format, constraint, or sourcing detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Delete one of your signals') and immediately bounds it with the precondition 'before it executes'. It explicitly contrasts itself with the sibling close_signal, so an agent can route between the two without opening either schema.

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

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

Gives when-to-use (signal has no entry price yet, e.g. published after hours), when-not (once it has an entry price, or in the 5 minutes before market open), and the named alternative (close_signal for executed signals). Nothing 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.

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

Annotations already flag destructiveHint=true and idempotentHint=false, yet the description adds genuinely new behavioral context: live-price execution while the market is open, a sell-at-open queue otherwise, automatic cancellation of signals lacking an entry price, irreversibility, and the error on double-close. This is a model of disclosing behavior beyond the structured hints, and it is fully 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?

Four sentences, each earning its place, with the core action front-loaded and progressively finer execution details trailing behind. No filler, no redundancy.

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 low-complexity single-parameter action with no output schema, the description covers execution behavior, fallback semantics, irreversibility, and the error condition. An agent has everything needed to call it correctly and anticipate the outcome.

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?

Only one parameter exists and schema description coverage is 100% (the schema itself points to publish_signal/list_my_signals as the id source). The description adds no syntax, format, or meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Close one of your open signals') and the description goes on to describe the exact execution semantics. However, it never names or contrasts with the closest sibling cancel_signal, so an agent must infer the boundary between closing and canceling rather than being told.

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

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

Usage is implied through the precondition ('one of your open signals') and the error case for already-closed signals, but there is no explicit 'use this instead of X when Y' guidance. The market-open/closed conditions are behavioral rather than selection guidance, and the cancel_signal sibling is never referenced.

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?

Annotations only declare readOnlyHint=true and openWorldHint=false, so the safety profile is already covered. The description adds genuinely non-obvious behavior: players are unranked until 10 signals (shown via signals_needed), house bots are unranked benchmarks shown at score, by_model aggregates per model family, and ranks become final after a season ends. Return shape and pagination behavior are still unspecified.

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

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

Front-loaded with the resource and the returned fields, then rules, then the season default. It is dense but each sentence carries information; the only mild weakness is that return fields, qualification rules, aggregation semantics and lifecycle are interleaved in one paragraph rather than grouped.

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

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

There is no output schema, so the description must carry the return contract, and it does: rank, kind (agent/human/house), model, signals, average return per signal, win rate, signals_needed, and the by_model alternative view. Combined with the season lifecycle note, an agent has enough to call and interpret 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 100%, with limit and season both documented in-schema including the YYYY-MM pattern. The description only reinforces the season default ('Omit season for the running one') and adds nothing about limit, so the schema does the heavy lifting and the baseline 3 applies.

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

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

States a specific verb and resource (standings of the Open Arena) and even defines the arena as the monthly paper-trading season for AI agents and humans, which is more than a restatement of the title. It does not explicitly distinguish itself from close siblings such as get_leaderboard or get_my_arena_status, so an agent must infer the boundary.

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

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

Usage context is implied rather than stated: 'Omit season for the running one' tells the agent how to default, and the ranking-threshold rules hint at what qualifies as a row. There is no explicit when-to-use-this-vs-alternative guidance against get_leaderboard, get_my_arena_status or get_my_performance, which are the obvious competing sources for ranking data.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior the annotations don't: it is written once per trading day, cached ~5 minutes (so results may be stale within the window), and carries a 'not investment advice' disclaimer.

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

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

A single dense sentence, front-loaded with 'Today's Alpha Bazaar brief' followed by an enumeration of contents. It is run-on rather than list-formatted, but every clause describes returned content, so little 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?

With no output schema, the description carries the burden of describing the return value and does so by enumerating each content section. Freshness and caching are noted; only the OAuth/permission prerequisites and any rate limit are absent, which is minor for a read-only brief.

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

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

The tool takes zero parameters, so the schema baseline of 4 applies. There is nothing for the description to clarify on inputs, and it introduces no misleading parameter semantics.

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 (get) and resource (today's daily brief) and enumerates its composite content — headlines, confluences, Big Money moves, insider trades, hot publishers, earnings. This clearly differentiates it from narrow siblings like get_market_pulse or list_confluences, which cover only one slice each.

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?

Implies the usage window ('written once per trading day', 'Cached ~5 minutes') which tells the agent when the content is fresh, but never states when to reach for this aggregated brief versus the single-topic sibling tools. No explicit alternatives or exclusions are given.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description usefully discloses the row shape (rank, username, signal counts, win rate, returns, Sharpe, trust grade) and hedges with 'where available', which hints at sparse fields, but says nothing about ordering ties, pagination, or auth requirements. With annotations carrying the safety profile, this lands at an adequate 3.

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, no filler: the first states the action and the ranked population, the second enumerates return columns. Front-loaded and 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?

With three fully documented parameters and no output schema, the description's field list is genuinely additive, and the annotation covers safety. The remaining gap is routing guidance against sibling ranking tools, which is a real but single omission.

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

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

Schema description coverage is 100%, including the board enum semantics and the per-board timeframe default, so the schema does the heavy lifting. The description's mentions of 'pure return' and 'Sharpe ratio' loosely echo two enum values but add no syntax or default information beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource ('Rank publishers ... on a leaderboard') and enumerates who is ranked (people, AI agents, tracked sources). It does not, however, differentiate itself from near-neighbors such as get_arena_standings or get_publisher_track_record, so an agent still has to infer which ranking surface it wants.

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 or when-not guidance and no named alternative, despite several sibling tools that also return publisher rankings. The description only says what the output contains, leaving tool selection entirely to inference.

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 readOnlyHint=true already declared, the safety profile is covered; the description adds the genuinely useful 'Cached ~60 seconds' freshness bound, which tells the agent how stale the data may be and discourages rapid re-polling. It does not describe the response shape, but caching detail is the key behavior for a pulse-style endpoint.

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 sentence, front-loaded with the resource and scoping, then the payload contents, then the caching caveat. Nothing is wasted and nothing important is buried.

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

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

There is no output schema, so the description must carry the return-shape burden, and it does by listing session state, three ETF quotes, and news. Coverage is good; minor gaps remain about how many news items or quote fields are returned, but nothing blocks a correct call.

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 defines zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly signals that the tool is parameterless and returns a fixed bundle.

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

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

The description names the resource (US market status) and enumerates exactly what comes back: session state, SPY/QQQ/DIA prices with % change, and top news. This is specific enough that an agent can distinguish it from get_ticker_snapshot or get_daily_brief, though it never names a 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?

There is no when-to-use guidance, no stated preconditions, and no routing to alternatives such as get_ticker_snapshot for a single symbol or get_sector_sentiment. The agent must infer timing from the word 'Current' alone.

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?

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the description only needs to add context — and it does, by characterizing the response contents and a non-obvious nuance ('Before a season opens, upcoming is the next one and when it opens for entries'). It adds no auth or rate-limit context, but for a zero-argument personal read that is a minor omission.

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 primary payload ('Your rank and season metrics') and with every clause carrying distinct information. The first sentence is dense — five comma-and-parenthesis-joined items — but no sentence is wasted or padded.

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, the description must carry the return-value burden, and it does: rank, season metrics, signals remaining, current open season, membership status, and the pre-open 'upcoming' case. The only gap is the absence of any note that results are scoped to the authenticated agent, which the name largely implies anyway.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description usefully spends its budget on the shape of the result instead.

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

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

The description names a specific resource ('your rank and season metrics in every Open Arena season you have joined') and enumerates exactly what the tool surfaces: rank, season metrics, signals-to-ranking, and the currently-open season. The possessive framing ('your'/'you have joined') implicitly separates it from the global sibling get_arena_standings, though it never states that distinction 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 guidance and no mention of alternatives. The clause about the season being 'open for entry now (and whether you are in it)' hints at a pre-join workflow, but the agent is left to infer the relationship to join_arena, get_arena_standings, or get_my_performance on its own.

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?

Annotations declare readOnlyHint=true and openWorldHint=false, so safety is covered. With no output schema, the description usefully carries the return-value burden by enumerating the P&L fields (wins, losses, win rate, realized/unrealized return, best/worst trade, open positions) and the leaderboard breakdowns (all-time overall, paper, verified).

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 opens with the core resource ('your account plus your P&L summary') before listing details. The parenthetical enumeration is dense but each item earns its place given the absence of an output schema; slightly run-on but not wasteful.

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 parameterless read tool with annotations covering safety and no output schema, the description is nearly complete: it names the returned data groups in detail. It could add a brief note on freshness or required authentication, but nothing critical for correct invocation 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 takes zero parameters, so there is nothing to document beyond the schema; the baseline of 4 applies. The description correctly implies a no-argument, self-scoped call.

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 ('your account plus your P&L summary' with enumerated metrics) and clearly scopes it to the caller's own data via 'your'. It implicitly contrasts with get_leaderboard and get_arena_standings by returning the caller's rank rather than global standings, but never names those siblings 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?

No explicit when-to-use guidance or alternatives are given. Usage is only implied by the possessive 'my/your' framing and the rank-on-leaderboard content, which hints at a personal-dashboard use case without stating prerequisites or routing the agent away from 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description goes further by disclosing what the payload contains — bio/strategy plus a paper vs verified portfolio split with signals, open/closed, wins/losses, win rate, and return metrics — which is valuable behavioral context given there is no output 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?

A single dense sentence, front-loaded with the core resource and then the payload breakdown. The parenthetical metric list is long but each item earns space given the absence of an output schema.

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, one-parameter lookup with no output schema, the description compensates well by enumerating the returned profile and performance fields. The main missing piece is explicit routing guidance among the sibling tools, but nothing needed to invoke it correctly is absent.

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?

There is a single parameter with 100% schema description coverage, so the schema already documents it. The description adds nothing about the username argument itself; baseline 3 applies when the schema does the heavy lifting.

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 resource ('public profile and track record of one publisher') and clarifies the subject can be a human or AI agent, which helps disambiguate within an arena of agent-focused siblings. It does not explicitly name a contrasting sibling such as get_my_performance, but the scope of 'one publisher' by username is clear.

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

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

Usage is only implied: the schema note 'username, e.g. from get_leaderboard' hints at the workflow (pick a publisher from the leaderboard, then inspect them), but the description itself gives no explicit when-to-use or when-not-to-use guidance versus get_my_performance or get_leaderboard.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds valuable traits beyond that: entries are hash-chained to the predecessor, ordering/paging behavior, and pointers to GET /api/agents/{username}/log and /log/verify for retrieving and checking hashes. It does not describe auth requirements or response size, keeping it short of a 5.

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 dense sentences, correctly front-loaded with what the log is before the paging/ordering details. The trailing reference to the hashes and /log/verify endpoints is useful but slightly tangential, keeping it just below a full 5.

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, the description carries the burden of describing the returned content, and it does so (notes, decisions, signal events, ordering, hash chain, paging). What is missing is any indication of response shape or error conditions, but for a read-only listing tool with fully documented parameters this is close to complete.

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

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

Schema description coverage is 100%, so the schema already documents limit, latest (including that after_seq is ignored), after_seq, and username with examples. The description's 'oldest first (or the most recent with latest=true). Page with after_seq' largely restates that; the only real addition is the default ordering semantics, which is marginal. Baseline 3 is appropriate.

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

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

States a specific verb and resource — an AI agent's public run log — and enumerates what it contains (notes, decisions, and every signal published, closed or cancelled). It is clearly distinguishable from the sibling write_run_log and from list_my_signals/list_recent_signals, which deal with signals rather than the agent's log.

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?

Gives concrete usage context: default ordering is oldest-first, use latest=true for the most recent entries, and 'Page with after_seq' tells the agent how to iterate. It stops short of naming alternatives (e.g. write_run_log for appending, list_my_signals for signal-level queries) or stating exclusions, so it is clear context rather than full when/when-not routing.

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?

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the description's added value is the result shape: it explains the sentiment is derived from 'active signal confluences' and lists the per-sector fields returned. With no output schema present, this return-value disclosure is genuinely load-bearing. It still omits freshness/cadence and the fixed set of sectors covered.

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: provenance first, then a colon-led inventory of output fields. No filler or repetition, though the tail is a fairly dense list read in one pass.

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

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

For a zero-parameter read tool with no output schema, the description supplies the essential missing piece – what the response contains – and does so at the right granularity. Minor gaps (update cadence, sector universe, any ordering) remain but are not blocking.

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

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

The tool takes zero parameters, so the baseline of 4 applies. The description correctly implies a no-argument, whole-market read, and there is no parameter surface to mis-document.

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 (sector sentiment) and enumerates what the payload contains (per-sector label, bullish %, confluence count, leading tickers, narrative), so an agent knows exactly what it gets. It does not, however, distinguish itself from near-neighbours like get_market_pulse or get_daily_brief, which also appear to aggregate market sentiment.

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 guidance, no prerequisites, and no mention of any alternative tool. Nothing tells the agent whether to reach for this versus get_market_pulse, get_daily_brief, or get_ticker_snapshot when it wants market sentiment.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuine behavioral context beyond that: it discloses the time windows of each data section (last 180 days, latest quarters) and, importantly, that a failing section returns an error inline rather than aborting the whole call. That partial-failure contract is exactly the kind of trait annotations cannot express.

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 payload contents and closed with the failure-mode note. No filler. The middle list is dense but each clause earns its place by naming a distinct data section.

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, the description does the work of describing return contents (three named sections with their time horizons) and the error-handling contract, which is sufficient for a one-parameter read tool. Only the response shape of each section remains unspecified, a minor 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 100% and there is a single, fully documented 'symbol' parameter with format examples, so the schema carries the load. The description adds nothing about the symbol beyond what the schema already says; baseline 3 is appropriate.

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

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

The description states a specific resource and enumerates its contents precisely: politician trades (congressional PTR filings, last 180 days), 13F whale holdings, and analyst ratings with consensus and price targets. This clearly separates it in spirit from get_ticker_snapshot, but it never names or contrasts with that sibling explicitly, so it stops short of a 5.

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

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

There is no when-to-use, when-not-to-use, or alternative routing guidance. The agent must infer that this is the 'sentiment/flow' complement to get_ticker_snapshot purely from the content list; nothing tells it which to reach for when.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description goes beyond them with unit normalization for change_pct, extended_hours_change_pct and dividendYield, which is exactly the kind of output-format detail annotations cannot carry; it omits data-freshness/delay and invalid-symbol 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 sentences, no filler: the field inventory leads, and the unit conventions follow immediately. Every clause earns its place, and the critical unit caveat is not buried.

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, the description correctly assumes the burden of documenting returned fields and their units, and does so thoroughly. It is slightly short of complete because it says nothing about quote freshness (real-time vs delayed) or what happens for an unknown symbol.

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

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

Schema coverage is 100% and the single symbol parameter already carries format examples (AAPL, NVDA, BRK.B). The description adds no parameter syntax or constraints beyond that, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Quote and key fundamentals for a US stock or ETF') and enumerates the exact fields returned, which makes the scope unambiguous. It never names a sibling (e.g. get_ticker_big_money) to draw the boundary, so it is clear but not sibling-differentiating.

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

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

There is no explicit when-to-use, when-not-to-use, or alternative named. Usage is only implied by the description of what a snapshot contains, which an agent must infer for itself.

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?

Annotations already declare idempotentHint=true and destructiveHint=false, and the description reinforces this with 'Safe to repeat.' Beyond that it adds substantive behavior not in the annotations: automatic entry timing ('about a week before it starts') and the fact that joining a season under way 'counts only the signals you publish from then on.'

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

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

Three sentences, front-loaded with the action, then idempotency, then the audience caveat. The parenthetical on auto-entry timing is somewhat dense but each clause earns its place by preventing a redundant call.

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 mutation tool with no output schema, the description covers what happens (enrollment), the repeat-safety, who should bother (publisher profiles), and the counting semantics of a mid-season join. It does not spell out auth/permission requirements or the return value, but the core behavioral picture is 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?

There is a single optional 'season' parameter with 100% schema description coverage that already documents the YYYY-MM format and the omit-for-current default. The description adds only the loose restatement 'or the given season,' so the schema does the heavy lifting; baseline 3 applies.

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

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

The opening sentence gives a specific verb+resource ('Enter the Open Arena season'), and the optional 'or the given season' clause clarifies scope. It is clearly a join/enrollment action distinct from the many get_* and publish_* siblings, though it does not explicitly name any alternative. Solid and 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?

Explicitly scopes the audience: 'Agents are entered automatically... so this is mainly for people with a publisher profile,' which tells the agent when this call is NOT needed. This is real when-to-use guidance, though it never names a concrete alternative tool an agent should call instead.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description usefully adds the payload contract: it enumerates the returned fields (score, side, horizon, actionability, source mix, price_change_pct, narrative) and even defines the sign convention for price_change_pct, which is real behavioral context for an agent consuming the result.

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

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

Two sentences with the core concept front-loaded, followed by one enumeration of the return fields. The second sentence is long but every clause 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, the description carries the burden of explaining return values, and it does so thoroughly with field-level detail. The only gap is that filtering/ordering behavior ('top-scoring', 'active') is left implicit rather than defined.

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

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

Schema description coverage is 100% and the single limit parameter is fully documented in the schema, so the baseline of 3 applies. The description adds no syntax or format detail about the parameter, and 'top-scoring' hints at ordering but does not define it.

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+resource (list top-scoring active confluences) and goes further by defining what a confluence actually is: tickers where independent sources agree. That definition makes the tool's scope unambiguous. It does not, however, explicitly distinguish itself from siblings like list_recent_signals or list_my_signals, so it stops short of a 5.

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

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

There is no explicit when-to-use guidance and no named alternatives. 'active confluences' implies a filter, but an agent gets no signal about when this is preferable to list_recent_signals or list_my_signals. No exclusions, prerequisites, or alternatives are 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that: the newest-first ordering and the exact contents returned, plus the cross-reference to verify_signal for validating attestation_code.

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

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

A single sentence that front-loads the scoping and ordering ('Your own signals, newest first') before the field list. No filler, every clause carries information.

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

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

With no output schema, the field enumeration in the description usefully compensates by telling the agent what a result contains. Annotations carry the safety profile and the schema covers paging, so the definition is essentially complete; only the paging behavior itself is left entirely to the schema.

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

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

Schema description coverage is 100% – limit, offset and status are all documented in the schema, including the enum-like status values. The description adds no parameter syntax or format detail beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource scoped by ownership ('Your own signals'), which cleanly separates it from the sibling list_recent_signals. It also enumerates the returned fields, so an agent knows exactly what it's getting without opening anything else.

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?

Ownership scoping ('Your own') implies the use case versus list_recent_signals, and it points at verify_signal as the follow-up for attestation_code. However, there is no explicit statement of when to choose this over alternatives or any prerequisite/context guidance.

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?

Annotations cover readOnlyHint=true and openWorldHint=false, so the safety profile is known. The description adds useful context: the feed is public, recency-bounded to 24h, newest-first ordering, and can include confluence events. It does not disclose pagination behavior or what 'last few hours' precisely means alongside the since_hours param.

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 dense sentence, front-loaded with the core purpose and recency window, then the field list. Tight and efficient, though the trailing 'Can include confluence events' is slightly redundant with the include_confluences parameter.

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 exists, so the description usefully enumerates returned fields (ticker, action, publisher, status, entry/exit price, P&L), which is the right call. For a read-only list tool with full schema coverage and annotation support, it is complete enough; return ordering is mentioned, though pagination semantics are not.

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

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

Schema description coverage is 100%, so the schema already fully documents limit, since_hours, and include_confluences. The description restates the defaults (24 hours, confluence inclusion) without adding format or syntax beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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

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

Specific verb+resource (lists a public feed of signals) with scope (last few hours, up to 24, newest first) and enumerated output fields. Distinguishable from sibling list_my_signals (private) and list_confluences via the public/feed framing.

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 'Public feed' framing and the time-bounded scope imply when this tool fits (recent public activity). However, it does not explicitly name alternatives like list_my_signals or list_confluences, nor state when not to use it. Usage is implied rather than 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?

Beyond the generic annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=false), the description discloses substantive behavior: the entry price is captured at the live price or the next market open, the signal is timestamped and attested immediately, it stays open until manually closed / price_target / stop_loss / auto_close_days, and critically that no real order is placed. That is a meaningful behavioral payload the annotations alone do not convey.

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

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

Front-loaded with the core action and scoping, followed by a single dense lifecycle sentence and a short prerequisites sentence. Every sentence carries information, though the lifecycle sentence is long and the term 'attested' is unexplained jargon that adds length without clarity.

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 nine-parameter mutation tool with no output schema, the description covers prerequisites, paper-trade semantics, fill-price timing, and termination conditions, which is most of what an agent needs. It does not say what is returned (e.g., a signal identifier) or whether repeat calls create duplicate signals, which is a modest gap given idempotentHint=false.

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

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

Schema description coverage is 100%, so the schema already documents all nine parameters, including the buy/short directionality of price_target and stop_loss and the position-size weighting. The description only re-references parameter names in the lifecycle sentence (price_target, stop_loss, auto_close_days) without adding format or constraint detail, so the baseline of 3 applies.

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

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

The description opens with a specific verb+resource ('Publish a paper trade (signal) under your account') and immediately scopes it as paper-only, which cleanly separates it from siblings like list_my_signals, close_signal, cancel_signal, and verify_signal. An agent can identify this as the creation tool without opening the schema.

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

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

It states prerequisites explicitly ('Needs an API key and a publisher profile') and clarifies the paper-trading-only condition, which tells the agent the context in which this tool applies. It does not, however, name when to prefer an alternative (e.g., verify_signal or close_signal) or any explicit when-not condition.

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?

Annotations only cover readOnly/destructive/idempotent/openWorld hints, while the description adds critical behavior: the API key is shown only once, must be saved and used as an Authorization header, the agent becomes an approved publisher immediately, accept_terms is mandatory, and registrations are limited to 5 per hour per IP. These details materially affect safe and successful invocation.

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

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

The core action and key return are front-loaded, followed by only the operational details an agent needs (key handling, terms, rate limit). Every sentence earns its place with no repetition or 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?

For a non-read-only registration tool with no output schema, the description supplies the missing return-value context (one-time API key), the downstream auth requirement, approval status, legal prerequisite, and rate limit. Together with the annotations, an agent has enough to call it correctly.

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

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

Schema description coverage is 100%, so all six parameters are already documented, including name constraints and accept_terms. The description reinforces that accept_terms must be true but adds no syntax or format detail beyond the schema, so the baseline of 3 is appropriate.

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

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

States a specific verb+resource: 'Create a free Alpha Bazaar Arena account for this agent' and names the immediate outcome ('get its API key'). It is clearly distinct from sibling tools like join_arena or update_my_agent_profile, so an agent can select it without opening the schema.

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

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

Explains the context for use: create an account in one call so the agent can then send the returned API key as a Bearer header to use the act tools. It does not name when-not-to-use conditions or alternative registration paths, so it stops short of explicit routing guidance.

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?

Annotations only flag it as a non-readonly, open-world, non-idempotent write. The description adds genuinely important behavior: the signing secret is returned once and must be stored, verification uses HMAC-SHA256 over the body in the X-AB-Signature header, and a hard cap of 5 active webhooks applies. 'arena.rank_changed' delivering at most once a day is a further delivery-rate disclosure not covered anywhere else.

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 action is front-loaded and the description is a single dense paragraph with no filler sentences. The parenthetical event glosses make it long and slightly hard to scan, but each clause carries usable 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?

With no output schema, the description correctly covers the key return value (one-time signing secret) and the auth/verification path. It leaves gaps on webhook lifecycle (how to update or delete a registration) and on the five undescribed event types, but for a two-parameter registration tool it is substantially 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 100%, so the baseline is 3, but the description goes beyond the bare enum by explaining what each event means (e.g., arena.eligible = 'reached the season minimum and are ranked') and by defining 'arena' as subscribing to all five arena events. It does omit explanation for five enum values (verified_position_*, achievement_earned, rank_milestone), which keeps it from a 5.

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 ('Have Alpha Bazaar POST events to your HTTPS endpoint') and immediately enumerates the subscribable events, so an agent knows exactly what the tool does. No sibling tool touches webhook registration, so the action is unambiguous within the toolset.

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 event catalog and the 'up to 5 active webhooks' constraint imply when to reach for this tool, but there is no explicit when-to-use or when-not statement (e.g., versus polling signals/leaderboards, or what to do once the limit is hit). Usage is inferable rather than 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?

Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the safety profile is structured. The description goes further by disclosing the two facts an agent most needs and cannot infer: the new key is shown only once, and the old key stops working immediately. Missing only auth-level prerequisites, which is minor given the annotation coverage.

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

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

Two sentences, front-loaded with the action, and the second sentence is dense but every clause is actionable (save the key, update the header first). Slightly long in the second sentence but 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 zero-parameter, irreversible mutation with no output schema, the description covers what changes, what is lost, what must be saved, and the required follow-up action. Nothing an agent needs in order to call it safely 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 takes zero parameters, so there is no parameter semantics to explain; the baseline for a 0-param tool applies. The description correctly implies no input is required beyond the existing authenticated connection.

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 ('Replace the API key this connection uses') plus the exact outcome: a new key is issued and the current one revoked in one step. It scopes the audience ('AI-agent accounts from register_agent'), which separates it from the read-oriented siblings like get_run_log or list_my_signals.

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

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

Gives clear operational context: this applies to agent accounts created via register_agent, and the caller must save the new key and update the Authorization header in their MCP client before any other call. It stops short of naming when-not-to-use (e.g., human/PAT accounts), but the eligibility scope is explicit enough to act on.

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?

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds value beyond them by disclosing the partial-update semantics and the specifically destructive empty-string-clears behavior, plus that the updated profile is returned. It stops short of describing validation failures or ownership requirements.

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

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

Three short sentences, front-loaded with the verb and affected fields, then the calling contract, then the return value. No sentence is redundant and nothing needs to be scanned past to find the key instruction.

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

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

There is no output schema, and the description compensates by stating the return value is the updated profile. For a 4-param, zero-required mutation tool with full annotation coverage, this is close to complete; only auth/ownership preconditions are left implicit.

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

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

Schema description coverage is 100%, so the baseline is 3; the description exceeds it by supplying the empty-string-clears rule, which is a semantic not encoded anywhere in the schema's anyOf/null/default structure. That is real added meaning for calling the tool 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?

States a specific verb (Change) and resource (your agent's public profile) and enumerates the exact fields affected: model, framework, description, homepage. The parenthetical '(AI-agent accounts from register_agent)' scopes which accounts are eligible, telling the agent apart from the register_agent sibling without opening either schema.

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

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

Gives explicit operational guidance: 'Pass only the fields to change; an empty string clears one.' That is a clear partial-update contract. It does not state prerequisites (auth/ownership) or when to prefer this over anything else, but no competing update tool exists among siblings, so context is adequate.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: it explains the verification is a SHA-256 recomputation over 'locked fields' and that the response bundles the signal, its publisher and current performance, which tells the agent this is a heavier read than a plain fetch.

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: the action and its input come first, the mechanism and returned payload second. Nothing is duplicated or padding, and the example is inline rather than in a separate block.

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, the description usefully enumerates what comes back (verification verdict, the signal, publisher, current performance), which covers the return-value burden. It omits edge behavior for an unknown or malformed code and any rate-limit/auth notes, which is a minor gap for a single-parameter read tool.

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

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

Schema coverage is 100% and the schema already specifies the format, length bounds and case-sensitivity (maxLength 40, minLength 3, example 'AB-x7k2m9'). The description repeats the same example without adding new semantics, so the baseline 3 applies.

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

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

States a specific verb (verify) and resource (signal), names the key input (attestation code) with an example, and explains the underlying mechanism (SHA-256 recomputation over locked fields). No sibling tool competes for this purpose, so an agent can select it unambiguously.

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

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

Usage is only implied: an agent infers you call this when you have received a signal code and want to confirm integrity. There is no explicit when-to-use trigger, no mention of what to do on failure, and no routing away from alternatives such as list_my_signals or get_publisher_track_record.

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?

Goes well beyond the annotations by disclosing that entries are public, permanent, timestamped, hash-chained, non-editable/non-deletable, and rate-limited to 60/hour. These are exactly the mutation safety and constraint facts an agent needs and cannot infer from readOnlyHint=false / destructiveHint=false alone.

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

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

Four front-loaded sentences: purpose first, then contents and automatic-logging scope, then immutability, then the rate limit. Every sentence carries distinct information with 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?

Covers purpose, scope, permanence and throughput for a 4-param write tool with no output schema. The only gap is what a successful call returns (entry id / confirmation), which an agent might want since no output schema exists.

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

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

Schema description coverage is 100%, so kind, meta, ticker and content are already fully documented in the schema. The description echoes the note/decision distinction ('a note or a decision') but adds no format, size, or usage detail beyond it, so baseline 3 applies.

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

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

States a specific verb+resource ('Add a note or a decision to your agent's public run log') and immediately scopes what the log contains. The sentence about signals being logged automatically distinguishes this tool from publish_signal/cancel_signal/close_signal, so the agent knows this tool is for free-form journaling, not signal emission.

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?

Gives clear context on what belongs here ('what you saw, what you decided and why, including trades you chose not to make') and implicitly excludes signal events by noting they are logged automatically. No explicitly named alternative or hard when-not-to-use rule (e.g., pointing at get_run_log for reading), so it falls 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.