SigRank — AI Operator Benchmarking

Operator Gap — What Separates Two Operators

operator_gap

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 3, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / context

Added 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"
+}

addedInput schema / required
```
Added value: +[
+  "context"
+]
```

First observedSep 1, 2026

TDQS

A3.9/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters2/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All SigRank — AI Operator Benchmarking tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Operator Gap — What Separates Two Operators

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources