grader

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

No annotations provided, but the description indicates it is a read operation with no destructive behavior. It could explicitly state it has no side effects, but the 'Free, no key needed' implies easy access.

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 wasted words. First sentence defines purpose, second gives usage context. Extremely efficient.

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

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

Given the simplicity (no params, no output schema), the description fully informs the agent about the tool's purpose and usage context. Sibling tools list reinforces differentiation.

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?

No parameters (0 params, 100% schema coverage), so baseline is 4. The description adds value by explaining what the returned content includes, compensating for lack of output schema.

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

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

The description clearly states what the tool provides ('exact AgentSpec JSON schema + indicator list + grade-report shape') and distinguishes it from sibling tools by being a reference for constructing specs.

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 says 'Read this BEFORE constructing a spec for grade_strategy', giving clear when-to-use guidance and implying not to use for other purposes. Also mentions 'Free, no key needed'.

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 burden. It discloses that the tool returns honest aggregates and is free with no key needed, implying low risk. However, it does not specify update frequency or whether data is cached.

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: the first lists the content, the second states cost and access conditions. No unnecessary words.

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

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

With no output schema, the description lists many specific metrics but does not specify the format (e.g., object/array) or if any pagination exists. It is adequate for understanding, but could be more precise.

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

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

The input schema has 0 parameters, so the description's detailed explanation of what the tool returns (grade distribution, gate fail rates, etc.) adds full meaning beyond the empty schema.

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

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

The description clearly states it provides 'honest aggregates' over all strategies graded on Tessen, listing specific metrics like grade distribution and gate fail rates. This distinguishes it from sibling tools: get_grade_report focuses on individual grades, grade_strategy/grade_trade_record are for grading actions, and get_agentspec_reference is for reference data.

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 notes 'Free, no key needed,' implying easy access without authentication. However, it does not explicitly state when to use this tool versus alternatives, such as for initial exploration versus detailed analysis of a specific strategy.

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 full burden. It discloses that the tool is free and requires no authentication, which are key behavioral traits. It implies read-only operation but doesn't discuss rate limits or other potential behaviors.

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

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

Two concise sentences with no wasted words. The key information (purpose, parameter, free, no key) is front-loaded and sufficient.

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

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

Given the simple tool with one parameter and no output schema, the description covers all essential aspects: what it does, the parameter, and that it's free and public. No gaps are evident.

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 description adds semantic meaning to the gradeId parameter by specifying it is the ID from a tessen.ai/verify/... URL, which goes beyond the schema's type-only definition. However, no additional details about format or validation are given.

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

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

The description clearly states the tool fetches a grade report by gradeId, includes the URL format hint, and distinguishes itself as free and keyless from siblings that involve strategy or trading.

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 explicitly says it's for fetching existing grades and is free with no key needed, implying it's the right tool for public retrieval. It doesn't explicitly state when not to use it, but the context with sibling tools provides enough differentiation.

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 full burden. It discloses key behaviors: 60/40 chronological train/OOS split, fees modeled, five hard gates, return of full grade report and public verify URL. It also mentions the need for an API key. While it could detail side effects (e.g., creation of permanent URL), it provides substantial transparency, earning a 4.

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 extremely concise: two main sentences covering core functionality and methodology, plus a concise requirement and prerequisite note. Every sentence adds value, and the most critical information is front-loaded. No wasted words.

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

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

Despite having only one parameter and no output schema, the description covers the tool's purpose, methodology, constraints, and prerequisites. It explains the five gates and data split but does not detail the grade report structure or gate criteria. This is sufficient for an agent to use the tool, though additional context on output could be helpful.

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 only parameter, agentSpec, has a minimal schema description ('AgentSpec per get_agentspec_reference'). The tool description adds value by explaining that it's an AgentSpec object and referencing get_agentspec_reference for the full schema, which compensates for the schema's brevity. Thus, it scores 4.

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

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

The description clearly states the tool's function: backtest and grade an AgentSpec on 6 years of data with specific methodology. It uses a specific verb ('grade') and resource ('strategy/AgentSpec'), and mentions the prerequisite get_agentspec_reference, which helps differentiate from siblings. However, it does not explicitly contrast with grade_trade_record or get_grade_report, so a score of 4 is appropriate.

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 clear usage context: it requires an API key and recommends calling get_agentspec_reference first for the schema. This informs the agent about prerequisites but does not specify when not to use the tool or offer alternative tools for different scenarios. Thus, it scores 4.

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 full burden. It discloses key behaviors: requires API key, self-supplied data leads to 'Checked' marking, chronological split, and same gates as backtest. It does not cover error handling or validation behavior, but is fairly transparent for a grading 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?

Two sentences pack essential information: what it does, constraints (>=30 trades, 60/40 split), labeling nuance, and requirement. Every sentence adds distinct value with 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?

The description covers main behavior and constraints but omits output format details and explanation of 'same gates'. It does not clarify the optional risk_per_trade_pct parameter. Given no output schema and moderate complexity, it is somewhat incomplete.

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 adds no meaning to the parameters. The 'trades' parameter is described only by its schema constraints, and 'risk_per_trade_pct' is not mentioned at all. The description fails to compensate for the lack of schema documentation.

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

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

The description clearly states the tool grades the caller's own trade history (>=30 trades) rather than a backtest, with specific details like chronologically 60/40 split, same gates, and labeling as 'Checked' not 'Verified'. This distinguishes it from siblings like 'grade_strategy'.

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 explicitly contrasts with backtests ('instead of a backtest') and specifies the tool is for the caller's own trade history with minimum 30 trades. It implies when to use this over alternatives, though it lacks explicit 'when not to use' or alternative names.

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