SigRank benchmark MCP: cascade metrics, leaderboard, operator profiles, simulation, diagnostics.
Scored across 16 tools
Several clusters overlap heavily: benchmark_me/compare_to_field both compare a user's cascade to the live field, rank_paste/rank_windows/get_sigrank_standard_record all compute metrics without persisting, and diagnose_cascade/suggest_improvements/self_improve plus simulate_change/rank_if blur together. The individual descriptions are detailed, but an agent needs to read them closely to avoid selecting the wrong tool for 'how do I compare?' or 'what if I change...'.
All names are lowercase and snake_case, with consistent get_* and rank_* subgroups, but the wider set mixes verb phrases (benchmark_me, diagnose_cascade, simulate_change), noun phrases (operator_signature, field_anomaly), and sentence-like names (who_operates_like_me). The conventions are readable and predictable within subgroups but not uniform across the server.
16 tools is at the borderline upper bound and covers a wide analytic surface, but several tools could be consolidated without losing capability. The count is not excessive for benchmarking, but the overlapping clusters make the set feel heavier than it needs to be.
The server covers the core benchmarking lifecycle: metric computation, leaderboard and profile reads, field comparisons, diagnosis, simulation, improvements, signatures, and anomaly discovery. There are no write/persist endpoints, but that appears intentional, and the only notable gaps are nice-to-haves like historical leaderboard trends or cohort-filtered leaderboard queries.
Answers 'How good am I?' — benchmarks your token cascade against the live field. Takes 4 token pillars (or a codename), computes your cascade, then compares against the live leaderboard: percentile, rank, distance from median, distance from top 10%, strongest metric, weakest metric, and a one-line interpretation. This is the human-question tool — use it when someone asks 'am I a power user?' or 'how do I compare?'.
| Name | Required | Description | Default |
|---|---|---|---|
| input | No | Total input tokens. Required if codename is not provided. | |
| output | No | Total output tokens. Required if codename is not provided. | |
| window | No | Time window for field comparison (default 30d). | 30d |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." | |
| codename | No | Operator codename (alternative to providing pillars). If provided, fetches live profile from the board. | |
| cache_read | No | Cache-read tokens. Required if codename is not provided. | |
| cache_write | No | Cache-write tokens. Required if codename is not provided. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds meaningful behavioral detail: it takes either four token pillars or a codename, computes the cascade, and compares against the live leaderboard. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences front-load the purpose, then explain the mechanism and outputs without filler. The output list is slightly long but earns its place because there is no 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?
The description is nearly complete: it explains what the tool does, when to use it, what inputs are accepted, and what outputs to expect. A minor gap is not stating precedence or behavior if both codename and pillars are supplied, but that is an edge case.
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 schema documents each parameter. The description adds value by grouping input/output/cache_read/cache_write as '4 token pillars' and presenting codename as an alternative input mode, which helps an agent understand how to construct a valid 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?
The description clearly states the tool answers 'How good am I?' by benchmarking a token cascade against the live field. It specifies the exact outputs — percentile, rank, distances, strongest/weakest metric, interpretation — which distinguishes it from siblings like compare_to_field or get_leaderboard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit trigger phrasing: use it when someone asks 'am I a power user?' or 'how do I compare?', and calls it the human-question tool. It does not explicitly name alternatives or exclusion cases, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a 'YOU vs FIELD vs TOP 10% vs TOP 1%' comparison table for your cascade metrics. Takes 4 pillars or a codename, fetches the live leaderboard, and returns your metrics alongside field median, top quartile, top decile, and top percentile for yield, leverage, velocity, and SNR. Simple, useful, and immediately understandable.
| Name | Required | Description | Default |
|---|---|---|---|
| input | No | ||
| output | No | ||
| window | No | 30d | |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." | |
| codename | No | Operator codename (alternative to pillars) | |
| cache_read | No | ||
| cache_write | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds useful behavioral context beyond that: it fetches the live leaderboard, accepts either pillars or a codename, and returns a fixed shape of comparison statistics. It does not mention rate limits or failure behavior, but this is acceptable for a read-only comparison tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core content is compact and front-loaded, with the main output and input modes stated in the first two sentences. The closing sentence 'Simple, useful, and immediately understandable' is promotional filler that does not add operational value. Overall, however, the description is much tighter than typical tool descriptions and wastes very little space.
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 seven parameters, the description needed to explain both the return shape and the purpose of the numeric fields. It does explain the return statistics well, but it leaves the semantics of input, output, window, cache_read, and cache_write entirely unspecified. An agent would not know what values to supply for most parameters based on this description alone.
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 29%, so the description carries a heavy burden for parameter meaning. It explains the high-level input alternatives ('4 pillars or a codename') and the output metrics, but it never explains what input, output, window, cache_read, or cache_write actually control. The codename parameter is the only one given meaning in context, and even the '4 pillars' mechanism is not mapped to the schema fields.
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 a concrete deliverable: a 'YOU vs FIELD vs TOP 10% vs TOP 1%' comparison table for cascade metrics. It also names the specific percentile statistics and metrics included, which distinguishes it from generic leaderboard or benchmark siblings. This is a specific verb plus resource with a well-defined output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for comparing individual metrics against field distributions, but it does not explicitly say when to choose it over alternatives like benchmark_me, operator_gap, or get_leaderboard. There is no 'use this when...' or 'for X instead use Y' guidance. The usage context is clear only by inference from the title and output.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyzes your token cascade and diagnoses where you're leaking efficiency. Takes 4 token pillars and produces a ranked list of efficiency leaks with severity (critical/warning/info), findings, recommendations, and estimated Υ impact. Checks: cache leverage, velocity, SNR, cache creation ratio, input bloat, and 10xDEV compounding. Use this before simulate_change to understand what's wrong.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Total input tokens. | |
| output | Yes | Total output tokens. | |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." | |
| cache_read | Yes | Cache-read tokens. | |
| cache_write | Yes | Cache-write tokens. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior. The description adds meaningful behavioral detail beyond that: it explains the form of the output (ranked list with severity, findings, recommendations, estimated impact) and the specific dimensions analyzed, giving an agent a clear model of what calling this tool will reveal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficient: purpose is front-loaded, the output structure is summarized, the key checks are listed, and the usage cue appears at the end. Every sentence contributes information without repetition or padding.
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 correctly carries the burden of explaining return values, which it does clearly: ranked list, severity categories, findings, recommendations, and impact. Combined with full schema coverage for parameters and annotations for safety, an agent has enough context to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so every parameter is already documented in the input schema. The description adds only a light grouping concept ('4 token pillars'), which maps to the four numeric token parameters but offers no additional semantic detail over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Analyzes...diagnoses') and identifies the exact resource ('token cascade') plus the concrete output: a ranked list of efficiency leaks with severity levels, findings, recommendations, and impact. It also distinguishes itself from siblings by calling out 'simulate_change' as the next step, so an agent can tell this tool apart.
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 to use this tool before simulate_change, which gives a clear positional/contextual trigger. It does not enumerate when-not-to-use conditions for other siblings, but the named alternative and diagnostic framing provide solid usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds unusual operators, metric relationships, and outliers in the live leaderboard — without user prompting. Returns: highest velocity among below-median leverage operators, only top-50 operator with near-zero cache write, largest 30-day yield improvement, rarest signature, and extreme divergence. Powers automated micro-marketing and field insights.
| Name | Required | Description | Default |
|---|---|---|---|
| window | No | 30d | |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only and idempotent; the description adds compatible behavioral detail by noting it runs on the 'live leaderboard' and is intended for 'without user prompting' proactive use. It lists what the tool returns, though it does not cover data freshness or any potential cost/rate limits. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words: the first front-loads the action and behavior, the second enumerates return highlights and the intended use case. Every clause adds decision-relevant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two parameters, rich safety annotations, and no output schema, so the description partially compensates by listing specific return findings. However, it leaves the window parameter semantics ambiguous and provides no explicit alternative routing among the 15 sibling tools, making it adequate but not 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 only 50%; the context parameter is explained in the schema, but the window parameter has only an enum and no semantic explanation. The description does not mention how window affects the anomaly search or clarify why '30-day yield improvement' is listed when a window is selectable, so it fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Finds unusual operators, metric relationships, and outliers in the live leaderboard') and lists concrete outputs such as 'highest velocity among below-median leverage operators' and 'extreme divergence.' This clearly separates it from sibling tools like get_leaderboard or rank_windows, which focus on standard leaderboard retrieval or ranking.
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 clear context for when to invoke it: 'without user prompting' and 'Powers automated micro-marketing and field insights.' It does not explicitly name alternatives or state when not to use it, but the automation-oriented framing is enough to route the agent in most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the current public SigRank operator leaderboard. Returns ranked operators with Yield, Leverage, class tier, and display name.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of operators to return (1–100, default 25). | |
| window | No | Time window for the leaderboard: 7d, 30d, 90d, or all_time. | 30d |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." |
| Name | Required | Description |
|---|---|---|
| window | No | The time window used for the query. |
| entries | No | |
| total_operators | No | Number of operators returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds 'public' and 'current' as behavioral context, but it does not disclose pagination, rate-limit, or data-freshness behavior beyond that.
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 identifies the operation and object, and the second enumerates the returned fields. Every sentence earns its place, with no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given rich annotations, full schema coverage, and an output schema, the description provides enough to invoke the tool correctly: what it reads and what it returns. It falls short only in signaling when to prefer this tool over its numerous siblings, which is a usage-guidance gap rather than a call-correctness 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%, so the parameters (limit, window, context) are already well documented. The tool description adds no parameter-level semantics; the listed return fields concern output, not parameters, which is acceptable at the schema-covered baseline.
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 starts with a concrete verb and resource: 'Read the current public SigRank operator leaderboard,' and it lists key return fields (Yield, Leverage, class tier, display name). It stops short of an explicit sibling contrast, so differentiation from tools like get_operator or rank_windows is implied by the term 'leaderboard' rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to call this tool versus the many sibling tools, nor does it mention any exclusions or prerequisites. An agent must infer from the tool name and title that a leaderboard query is intended, which is thin guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one public operator profile by codename. Returns class tier, rank, percentile, Yield, Leverage, Velocity, and SNR.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." | |
| codename | Yes | The operator's unique codename (e.g. signal-ae3b5c3c55). Not the display name. |
| Name | Required | Description |
|---|---|---|
| snr | No | Signal-to-noise ratio. |
| rank | No | Global rank position. |
| yield_ | No | Yield (Υ) if compounding, else null. |
| codename | No | Operator's unique codename. |
| leverage | No | Leverage if compounding, else null. |
| velocity | No | Velocity = output / input. |
| class_tier | No | Operator class tier. |
| percentile | No | Percentile in the public field. |
| display_name | No | Human-readable display name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the profile is public and that exactly one profile is read, but it does not disclose additional behavioral details such as auth requirements, rate limits, or error 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?
The description is a single front-loaded sentence with no filler. Every phrase adds information: action, scope, lookup key, and returned 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?
This is a simple read operation with fully documented parameters, supportive annotations, and an output schema. The description plus schema covers everything needed to call the tool correctly; no return-format explanation is necessary.
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 codename and context. The description adds only 'by codename' and a list of return fields, which does not materially extend the 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?
The description uses a specific verb ('Read') and resource ('one public operator profile by codename') and lists the returned fields, making its purpose clear. It does not explicitly distinguish itself from siblings like operator_signature or get_sigrank_standard_record, but the output-field list helps narrow the intended use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool instead of sibling tools such as get_leaderboard or operator_signature. The phrase 'by codename' implies a lookup use case, but there are no explicit conditions, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a SigRank Standard v0.1-draft portable operator record from available token telemetry. Input and output are required; unavailable cache telemetry remains null. Computes only the five-metric portable core through @sigrank/cascade and does not submit or persist data.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | No | Optional tool/client identifier. | |
| input | Yes | Fresh input tokens. | |
| model | No | Optional model identifier. | |
| output | Yes | Output tokens. | |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." | |
| provider | No | Optional provider identifier. | |
| timestamp | No | Optional ISO-8601 timestamp. Defaults to the current time. | |
| cache_read | No | Cache-read tokens, or null when unavailable. | |
| cache_write | No | Cache-write / cache-creation tokens, or null when unavailable. |
| Name | Required | Description |
|---|---|---|
| spec | Yes | |
| source | Yes | |
| metrics | Yes | |
| warnings | Yes | |
| telemetry | Yes | |
| timestamp | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only, idempotent, and non-destructive, and the description adds meaningful behavioral detail: it 'does not submit or persist data', leaves unavailable cache telemetry as null, and computes only through @sigrank/cascade. This gives the agent confidence about side effects beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler; the purpose is stated first and the constraining behavioral details follow immediately. 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 a rich output schema, 100% parameter coverage, and annotations, the description does not need to restate return values or safety. It supplies the missing operational context: required inputs, null handling for cache, and non-persistence. It only omits an explicit tie to sibling selection, which is already penalized under usage guidelines.
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 does not materially extend the schema. It restates that input/output are required and cache values may be null, which echoes the schema rather than adding new parameter-level meaning.
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 ('Build') and a precise resource ('SigRank Standard v0.1-draft portable operator record'), then scopes the operation to 'available token telemetry' and the 'five-metric portable core'. This is clearly distinct from sibling tools like diagnose_cascade or rank_if, so an agent can tell what this tool uniquely produces.
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 clear invocation requirements: 'Input and output are required' and unavailable cache telemetry stays null. However, it never names alternative tools or says when to prefer this over siblings such as rank_if or get_operator; the selection context is only implied by the narrow scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Answers 'What specifically separates operator A from operator B?' — not just 'A has more Yield', but the primary cause, secondary cause, and offsetting weakness. Takes two codenames or two sets of pillars, computes both cascades, and decomposes the yield gap into leverage, velocity, SNR, and scale contributions. Returns the most explanatory factor.
| Name | Required | Description | Default |
|---|---|---|---|
| a_input | No | ||
| b_input | No | ||
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." | |
| a_output | No | ||
| b_output | No | ||
| a_codename | No | Codename for operator A (alternative to a_* pillars) | |
| b_codename | No | Codename for operator B (alternative to b_* pillars) | |
| a_cache_read | No | ||
| b_cache_read | No | ||
| a_cache_write | No | ||
| b_cache_write | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so no side-effect disclosure is needed. The description adds process and output behavior beyond annotations: it computes cascades, decomposes the yield gap into leverage, velocity, SNR, and scale contributions, and returns the most explanatory factor. This is meaningful behavioral context and is consistent with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words. It front-loads the core question in the first sentence, describes the process and inputs in the second, and states the output in the third. Every sentence earns its place and the structure makes the tool easy to grasp quickly.
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?
This is a data-rich tool with 11 parameters, 27% schema coverage, and no output schema, yet the description does not map the pillar-related parameters to specific inputs or explain how codenames and pillar sets interact. It also gives only a high-level description of the return value ('most explanatory factor') without detailing the output format or whether the full decomposition is also returned. For an agent to call this correctly, more information is needed.
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 27%, so the description must compensate for the undocumented numeric parameters. It explains that two codenames or two sets of pillars can be provided, but it never defines what a_input, a_output, a_cache_read, or a_cache_write mean or how they form a pillar. It does not clarify required versus optional behavior, leaving most parameters semantically ambiguous.
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 verb and resource: it 'Answers' a precise question about what separates operator A from operator B. It goes beyond the title by contrasting itself with a simpler 'A has more Yield' comparison, which distinguishes it from sibling comparison tools like compare_to_field or who_operates_like_me. The purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the context clear: use this when the question is about the specific causes of a yield gap between two operators, not merely which one is higher. It implicitly rules out simpler comparisons by saying 'not just A has more Yield', but it does not explicitly name alternative tools or state when-not-to-use scenarios. This is clear usage context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Computes a normalized operating signature from 4 token pillars or a codename. Returns a signature code, a legacy six-label signature_label, dominant trait, and closest comparable operators from the live board. The deprecated archetype field is retained as a compatibility alias; these labels are not the 10-type Build Archetypes reference extension.
| Name | Required | Description | Default |
|---|---|---|---|
| input | No | ||
| output | No | ||
| window | No | 30d | |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." | |
| codename | No | Operator codename (alternative to pillars) | |
| cache_read | No | ||
| cache_write | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: it computes a normalized signature from pillars or codename, returns several derived fields, and clarifies that the deprecated archetype field is a compatibility alias not part of the 10-type Build Archetypes. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three dense sentences with the primary purpose front-loaded and no filler. The disambiguation sentence is useful, though the heavy jargon may reduce clarity for an agent encountering this tool for the first time.
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 7 parameters, low schema coverage, and no output schema, the description should provide more complete guidance but omits parameter-level semantics for window, input, output, cache_read, and cache_write. It lists return fields but does not explain their format or relationship to the inputs, leaving significant gaps 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 only 29%, so the description must compensate for poorly documented parameters, but it only mentions '4 token pillars or a codename' without mapping those to specific parameters like input, output, cache_read, cache_write, or window. The description adds some semantic value but leaves most parameter meanings unclear.
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 a specific verb ('Computes') and resource ('normalized operating signature'), and it names the main inputs and outputs. It does not explicitly distinguish this tool from siblings like who_operates_like_me or get_operator, though it does disambiguate from the Build Archetypes reference extension.
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 explains what the tool computes but provides no guidance on when to use it versus alternatives such as who_operates_like_me or get_operator. There is no mention of prerequisites, conditions, or exclusions, so an agent must infer usage purely from the output description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Answers 'What would it take to reach a target rank?' — takes your current 4 token pillars and a target percentile (e.g. 90 for top 10%), then simulates the smallest metric changes needed to reach that position. Returns: current rank/percentile, simulated rank/percentile, the specific pillar changes required, and the yield delta. This turns SigRank from a scoreboard into a simulator. Use it when someone asks 'what would move my rank?' or 'how do I get to top 10%?'.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Current input tokens. | |
| output | Yes | Current output tokens. | |
| window | No | Time window for field comparison (default 30d). | 30d |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." | |
| cache_read | Yes | Current cache-read tokens. | |
| cache_write | Yes | Current cache-write tokens. | |
| target_percentile | Yes | Target percentile (0-100). E.g. 90 for top 10%, 99 for top 1%. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds meaningful behavioral context beyond that: it states the tool simulates changes rather than applying them, and it enumerates the return fields including current rank, simulated rank, required pillar changes, and yield delta.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet complete, with each sentence serving a distinct purpose: the motivating question, the mechanics, the return values, a high-level positioning statement, and concrete trigger phrases. No sentence is wasted, and the most important behavior is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description compensates by explicitly listing the returned data points. It covers the target percentile with examples, names the input pillars, and gives clear user-facing trigger questions. Combined with 100% schema coverage and read-only annotations, an agent has enough context to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all seven parameters. The description adds value by framing input/output/cache_read/cache_write as '4 token pillars' and by giving an example interpretation of target_percentile (90 for top 10%), but it does not substantially go beyond the schema's detailed parameter descriptions.
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 uses a specific question-based framing: 'Answers What would it take to reach a target rank?' and clearly identifies the resource (SigRank metric pillars) and the operation (simulating smallest metric changes). This distinguishes it from simple ranking or leaderboard tools because it emphasizes counterfactual simulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use-case triggers: 'Use it when someone asks what would move my rank? or how do I get to top 10%?' This is clear contextual guidance. However, it does not explicitly differentiate from the sibling tool simulate_change or say when not to use it, so it stops short of full when-not/alternative coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate SigRank cascade metrics from four non-negative token counts without submitting data. Returns Yield, Leverage, Velocity, SNR, and 10xDEV. No data is persisted.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Total input tokens consumed in the session. | |
| output | Yes | Total output tokens generated. | |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." | |
| cache_read | Yes | Tokens read from prompt cache (reused context). | |
| cache_write | Yes | Tokens written to prompt cache (new context stored for reuse). |
| Name | Required | Description |
|---|---|---|
| snr | No | Signal-to-noise ratio = output / (input + output). Null when input is zero. |
| input | No | Echoed input token count. |
| dev10x | No | log₁₀(Leverage). Logarithmic context amplification. |
| output | No | Echoed output token count. |
| yield_ | No | Yield (Υ) = (cache_read × output) / input². Headline cascade efficiency. Null when input is zero. |
| leverage | No | Leverage = cache_read / input. Reusable context amplification. Null when input is zero. |
| velocity | No | Velocity = output / input. Output per unit of input. Null when input is zero. |
| cache_read | No | Echoed cache-read token count. |
| cache_write | No | Echoed cache-write token count. |
| non_compounding | No | True if cache_write is zero (no compounding context). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=true and idempotent=true, and the description adds meaningful context beyond that: no data is submitted and no data is persisted. This helps an agent understand privacy and side-effect behavior without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences front-load the core purpose, list the return metrics, and state the key privacy guarantee. There is no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, input category, outputs, and side-effect behavior, and an output schema exists so return details do not need to be repeated. It is slightly incomplete only in that it mentions four token counts while the schema has five required parameters, though the fifth context parameter is fully described in 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%, so the schema itself documents each parameter well. The description adds general context that the numeric inputs are non-negative token counts, but it does not go into parameter-specific meaning beyond what the schema already provides.
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 specific action: calculating SigRank cascade metrics from four token counts, and even lists the exact metrics returned (Yield, Leverage, Velocity, SNR, 10xDEV). The 'Local Token Cascade Calculator' title and 'without submitting data' differentiate it from other rank/cascade siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the appropriate use case: local, privacy-preserving token cascade calculation where data is not submitted or persisted. However, it does not explicitly state when to prefer this tool over alternatives like diagnose_cascade or other rank-related tools, nor does it give exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score up to 4 time windows (7d, 30d, 90d, all-time) in one call. Each window is scored independently with the full cascade (Υ, SNR, Leverage, Velocity, 10xDEV, class). Omit windows you don't have — partial input is allowed (1-4 windows). Does NOT submit to the board.
| Name | Required | Description | Default |
|---|---|---|---|
| 7d | No | 7-day window token pillars (optional) | |
| 30d | No | 30-day window token pillars (optional) | |
| 90d | No | 90-day window token pillars (optional) | |
| all | No | All-time window token pillars (optional) | |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, and the description adds genuinely useful behavioral context: each window is scored independently, the full cascade is applied, and no board submission occurs. This goes beyond the structured annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four short, dense sentences, each contributing a distinct piece of information: multi-window scope, independent cascade scoring, partial-input allowance, and no board submission. It is front-loaded with the most important detail and contains 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?
With schema and annotations covering parameter shapes and safety, the description supplies the remaining operational context: window names, cascade stages, partial-input rule, and the absence of submission. A minor gap is that no output schema exists and the description does not explicitly state the return shape, though the cascade list strongly implies the scored result.
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 adds value by clarifying that windows can be omitted, partial input of 1-4 windows is allowed, and each window is scored independently. This helps an agent understand optional-window behavior beyond what the schema's 'optional' flags convey.
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 and resource: 'Score up to 4 time windows (7d, 30d, 90d, all-time) in one call.' It also names the exact cascade stages and explicitly states 'Does NOT submit to the board,' which differentiates this tool from sibling ranking/submission tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly tells the agent when to use the tool: for multi-window scoring, with partial input allowed (1-4 windows) and omitted windows permitted. The 'Does NOT submit to the board' line provides an exclusion, but the description does not name a specific alternative sibling or fully explain when to prefer rank_if or rank_paste.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs the full self-improvement cycle in one call: (1) computes your current cascade from 4 token pillars, (2) diagnoses efficiency leaks, (3) generates ranked improvement suggestions, (4) simulates the top suggestion, and (5) returns the complete cycle: diagnosis + suggestions + simulated impact of the best change. The 'one-click optimize' tool — call it at the end of a session to see what to improve next time.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Total input tokens. | |
| output | Yes | Total output tokens. | |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." | |
| cache_read | Yes | Cache-read tokens. | |
| cache_write | Yes | Cache-write tokens. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds value by disclosing the exact pipeline: compute, diagnose, suggest, simulate, return. It also clarifies that the impact is 'simulated', so no actual changes are made.
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 primary purpose front-loaded and the pipeline organized as a numbered list. The usage guidance in the second sentence is concise and 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 no output schema, the description adequately explains what is returned: diagnosis, suggestions, and simulated impact. It also clarifies the input source and the appropriate invocation timing, making the tool fully comprehensible for selection and use.
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 parameter descriptions already carry the burden. The tool description adds marginal value by grouping the four numeric token inputs as '4 token pillars', which helps the agent understand their collective role, but it does not add further parameter-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Runs') and a specific resource ('the full self-improvement cycle'), then enumerates five concrete steps. It clearly distinguishes itself from sibling tools like diagnose_cascade, simulate_change, and suggest_improvements by positioning itself as the all-in-one composite.
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 clear usage context: call at the end of a session to see what to improve next time. It does not explicitly name alternative tools or say when not to use them, but the 'full cycle in one call' contrast makes the composite nature obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prescriptive 'what if' tool — takes your current 4 token pillars and proposed changes, runs the cascade on both, returns the exact Υ Yield delta, class change, and per-metric diffs. Test proposed pillar changes and see the payoff before changing your workflow. Changes can be absolute numbers (replace) or strings starting with +/- for relative deltas.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Current input tokens. | |
| output | Yes | Current output tokens. | |
| changes | Yes | Proposed changes. Keys: input, output, cache_read, cache_write. Values are absolute numbers (replace) or strings starting with +/- for relative deltas. Omitted pillars are unchanged. | |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." | |
| cache_read | Yes | Current cache-read tokens. | |
| cache_write | Yes | Current cache-write tokens. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds behavioral value by explaining it 'runs the cascade on both' current and proposed states, returns specific result types, and supports absolute values or '+/-' relative deltas. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler: behavior and outputs are front-loaded, followed by usage intent, then value-syntax guidance. Every sentence earns its place and the structure supports quick agent scanning.
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?
This is a complex tool with 6 required parameters, a nested changes object, and no output schema. The description covers the core outputs (Υ Yield delta, class change, per-metric diffs) and the invocation scenario. It could go deeper on the exact output shape or explicitly mention how the four token pillars map to parameters, but the rich input schema largely carries that burden.
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 parameter meanings, including the absolute-vs-relative change syntax. The description reinforces this behavior but does not add significant new field-level semantics beyond what the schema provides, 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?
The description clearly identifies the tool as a 'what-if' simulator with a specific verb ('simulate'), resource ('4 token pillars... cascade'), and distinctive output (Υ Yield delta, class change, per-metric diffs). This differentiates it from siblings like diagnose_cascade or suggest_improvements.
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 states when to use it: 'Test proposed pillar changes and see the payoff before changing your workflow.' It gives clear context but does not name sibling alternatives or provide explicit 'use X instead' routing, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates ranked, simulated improvement suggestions for your token cascade. Takes 4 token pillars, tests multiple strategies (increase cache reads, reduce input, increase output, optimize cache creation), simulates each, and returns them ranked by Υ yield impact. Each suggestion includes the action, pillar to change, projected Υ, yield delta, projected class, and rationale. Returns the single highest-impact change as best_single_change.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Total input tokens. | |
| output | Yes | Total output tokens. | |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." | |
| cache_read | Yes | Cache-read tokens. | |
| cache_write | Yes | Cache-write tokens. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavior beyond the annotations: it is explicitly 'simulated,' tests multiple strategies, returns ranked results, and includes a best_single_change field. This aligns with readOnlyHint and idempotentHint and makes clear that no real mutation occurs.
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 three sentences, front-loaded with the core action, then efficiently covers strategy, simulation, ranking, output fields, and best_single_change. Every sentence adds necessary information without 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?
With no output schema, the description compensates by enumerating the suggestion fields and best_single_change. Combined with complete parameter descriptions and safe annotations, it gives an agent most of what it needs. A minor gap is the lack of explicit guidance on choosing this over simulate_change.
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. The description adds value by framing input, output, cache_read, and cache_write as the '4 token pillars' and linking them to strategies such as increase cache reads, reduce input, and optimize cache creation. It does not mention the context parameter, but the schema already documents its strict requirements.
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 and resource: 'Generates ranked, simulated improvement suggestions for your token cascade.' It then details the exact output fields and the ranking behavior, which clearly separates it from siblings like simulate_change or diagnose_cascade.
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 use case is clear: call this tool when you want multiple improvement strategies simulated, compared, and ranked. It does not explicitly name alternatives or state when not to use it, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds operators whose operating signature most resembles yours. Takes 4 pillars or a codename, computes your signature, then searches the live leaderboard for the nearest neighbors by signature distance. Returns: nearest operators, similarity %, where they outperform you, where you outperform them, and what separates you from the better operator. Makes the leaderboard feel like a network, not a list.
| Name | Required | Description | Default |
|---|---|---|---|
| input | No | ||
| limit | No | Number of nearest neighbors to return (default 5) | |
| output | No | ||
| window | No | 30d | |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." | |
| codename | No | Operator codename (alternative to pillars) | |
| cache_read | No | ||
| cache_write | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare the tool read-only and idempotent, and the description adds behavioral detail beyond that: it computes a signature, queries the live leaderboard, and produces a comparative breakdown including outperformance directions. No contradictory claims are present.
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 main functional flow is conveyed in two tight sentences and the return payload is listed compactly. The closing sentence ('Makes the leaderboard feel like a network, not a list') is stylistically nice but not functionally necessary, preventing a perfect score.
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 return fields are enumerated, which compensates for the missing output schema, and the processing flow is clear. But with eight parameters, no example, and an ambiguous '4 pillars' reference, the description is not complete enough for an agent to confidently construct a non-default 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?
Schema description coverage is only 38%, so the description must carry much of the parameter-meaning burden. It says 'Takes 4 pillars or a codename' but never maps the four pillars to the actual schema fields, leaving the numeric parameters ambiguous. Limit, window, and context are already explained in the schema, so the description adds little parameter-level value.
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 and resource ('Finds operators whose operating signature most resembles yours') and adds the discriminator 'nearest neighbors by signature distance.' This separates it from siblings like get_leaderboard or operator_signature, making the tool's unique purpose immediately 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?
It gives a clear usage context: pass four pillars or a codename, and it will compute a signature and search the live leaderboard for similar operators. However, it does not name alternative tools or explicitly state when not to use it, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
benchmark_me3 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / contextAdded value: +{
+ "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+ "type": "string"
+}Input schema / requiredAdded value: +[
+ "context"
+]compare_to_field3 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / contextAdded value: +{
+ "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+ "type": "string"
+}Input schema / requiredAdded value: +[
+ "context"
+]diagnose_cascade3 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / contextAdded value: +{
+ "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "input",
- "output",
- "cache_read",
- "cache_write"
-]New value: +[
+ "input",
+ "output",
+ "cache_read",
+ "cache_write",
+ "context"
+]field_anomaly3 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / contextAdded value: +{
+ "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+ "type": "string"
+}Input schema / requiredAdded value: +[
+ "context"
+]get_leaderboard3 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / contextAdded value: +{
+ "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+ "type": "string"
+}Input schema / requiredAdded value: +[
+ "context"
+]get_operator3 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / contextAdded value: +{
+ "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "codename"
-]New value: +[
+ "codename",
+ "context"
+]get_sigrank_standard_record3 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / contextAdded value: +{
+ "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "input",
- "output"
-]New value: +[
+ "input",
+ "output",
+ "context"
+]operator_gap3 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / contextAdded value: +{
+ "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+ "type": "string"
+}Input schema / requiredAdded value: +[
+ "context"
+]operator_signature3 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / contextAdded value: +{
+ "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+ "type": "string"
+}Input schema / requiredAdded value: +[
+ "context"
+]rank_if3 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / contextAdded value: +{
+ "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "input",
- "output",
- "cache_read",
- "cache_write",
- "target_percentile"
-]New value: +[
+ "input",
+ "output",
+ "cache_read",
+ "cache_write",
+ "target_percentile",
+ "context"
+]rank_paste3 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / contextAdded value: +{
+ "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "input",
- "output",
- "cache_read",
- "cache_write"
-]New value: +[
+ "input",
+ "output",
+ "cache_read",
+ "cache_write",
+ "context"
+]rank_windows3 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / contextAdded value: +{
+ "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+ "type": "string"
+}Input schema / requiredAdded value: +[
+ "context"
+]self_improve3 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / contextAdded value: +{
+ "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "input",
- "output",
- "cache_read",
- "cache_write"
-]New value: +[
+ "input",
+ "output",
+ "cache_read",
+ "cache_write",
+ "context"
+]simulate_change3 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / contextAdded value: +{
+ "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "input",
- "output",
- "cache_read",
- "cache_write",
- "changes"
-]New value: +[
+ "input",
+ "output",
+ "cache_read",
+ "cache_write",
+ "changes",
+ "context"
+]suggest_improvements3 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / contextAdded value: +{
+ "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "input",
- "output",
- "cache_read",
- "cache_write"
-]New value: +[
+ "input",
+ "output",
+ "cache_read",
+ "cache_write",
+ "context"
+]who_operates_like_me3 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / contextAdded value: +{
+ "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+ "type": "string"
+}Input schema / requiredAdded value: +[
+ "context"
+]benchmark_mecompare_to_fielddiagnose_cascadefield_anomalyget_leaderboardget_operatorget_sigrank_standard_recordoperator_gapoperator_signaturerank_ifrank_pasterank_windowsself_improvesimulate_changesuggest_improvementswho_operates_like_meClosed-source remote MCP: model benchmarks, costs, HN signals, tech registry.
Brand-intelligence MCP: momentum scoring, signal evidence, and competitive context for agents.
RMMCompare: the site's own MCP server — dataset, enquiry (enquiry = a human handoff, not a...
Papers With Code MCP — browse ML research papers and their code repositories
Add one secure layer between your agents and this server.