flopsindex-mcp

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

No annotations provided, so description carries full burden. It specifies the data source ('r15-contracts C3 citation contract'), lists exact return fields, and explicitly states what is omitted. This provides sufficient behavioral context for a read tool.

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

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

Two sentences: first describes the core action and return fields, second provides usage guidance. No wasted words; front-loaded with key information.

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

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

For a single-parameter fetch tool with no output schema, the description fully covers return fields, omissions, and source contract. No missing critical context needed for agent selection.

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

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

Only one parameter (index_id) with 100% schema coverage including examples. Description adds minimal value beyond schema (e.g., mentions 'FLOPS index id / slug'). Baseline 3 is appropriate.

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

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

The description clearly states the tool resolves a FLOPS index to its public payload, listing specific return fields. It distinguishes from siblings by noting what is deliberately omitted and provides a usage hint: 'Prefer get_index when you intend to CITE the value.'

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 advises when to prefer this tool ('when you intend to CITE the value'), but does not explicitly name sibling tools or state when not to use it. However, the context of deliberate omissions implies alternatives for source/providers info.

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

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

Discloses return fields, confidence levels, tier types, and intentionally notes 'carries no methodology or source attribution by design'. With no annotations, this adequately describes behavior.

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

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

Two clear sentences: first covers purpose and output, second covers usage and behavioral note. No unnecessary words.

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

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

Given simple inputs and no output schema, the description fully covers purpose, parameters, return format, and behavioral traits. An agent can use it confidently.

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?

Explains the single 'slug' parameter in detail with specific format examples (FLOPS-<MODEL>-OD, bare gpu_model, etc.), adding significant value beyond the schema description.

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?

Clearly states 'Fetch the current published value for a FLOPS compute or inference price index'. Specifies verb, resource, and scope, distinguishing it from siblings like get_timeseries or get_methodology.

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?

Indicates it's the 'cheapest way to answer "what does X trade at right now?"', providing context for when to use. Implicitly contrasts with more detailed tools. Lacks explicit alternatives but still useful.

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

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

With no annotations, the description adds important behavioral details: return format (JSON array of fields) and that no auth is required. This goes beyond a bare listing.

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

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

Two sentences, front-loaded with key purpose, no redundant information. Every word earns its place.

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

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

For a simple list tool with one optional parameter, the description covers purpose, return format, and usage context. No gaps given the low complexity.

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

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

Schema coverage is 100%, and the description only restates the optional filter exist. It adds no new meaning beyond the schema's description of 'Case-sensitive substring match'.

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 and resource ('List all public FLOPS compute-price indices') and explicitly distinguishes itself from siblings by advising use 'before calling get_price or verify'.

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?

Provides explicit context for when to use (before get_price/verify) and notes no authentication required. While no explicit when-not-to-use is given, the guidance is sufficient.

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

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

No annotations provided, so the description must convey behavioral traits. It describes the search/resolution operation but does not mention any side effects, auth requirements, or whether the operation is read-only. The description is adequate for a simple lookup, but not rich enough to fully compensate for the lack of 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 sentences with an example, front-loaded with purpose. Every word adds value, no redundancy. Extremely concise and well-structured.

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

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

Given the simple tool (2 params, no output schema), the description covers purpose, usage, and a workflow tip. It does not describe the return format or pagination behavior for 'limit', but the tool is straightforward enough that this is a minor gap.

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

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

Schema coverage is 50% (only 'q' has a description in the schema, but 'limit' is documented via schema metadata). The description adds valuable context for 'q' via an example ('b300 nordics on-demand'), but does not address 'limit' at all. Given the moderate coverage, the description provides useful but incomplete parameter clarification.

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?

Describes the tool as resolving a free-text query to canonical FLOPS index slugs, using a clear verb and resource. Distinguishes from siblings like list_indices (which lists all indices) and get_index (which retrieves a specific index by slug).

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

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

Explicitly states when to use: 'Use when you don't know the exact slug' with a concrete example. Suggests pairing with get_price for a common workflow. Lacks explicit when-not-to-use, but the context is clear enough.

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

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

No annotations are provided, so the description must disclose behavior. It states it returns four specific data items, implying read-only operation, but does not mention error conditions, rate limits, or authentication requirements. The behavior is partially transparent.

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 two sentences with no redundant clauses. It front-loads the action and return values, making it easy to parse. Every sentence adds value.

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 no output schema, the description explains the return values (value, methodology pointer, source-count, audit receipt). It does not cover error handling or edge cases, but for a simple verification tool, it is sufficiently complete.

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

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

Schema coverage is 100% with a descriptive parameter doc ('FLOPS index identifier (e.g. 'FLOPS-H100-OD-T1', …)'). The description adds no additional meaning beyond the schema. Baseline 3 applies.

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

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

The description clearly states the tool verifies a FLOPS index value and lists specific return fields (latest published value, methodology pointer, source-count, audit receipt). The verb 'verify' and resource 'FLOPS index value' are specific. It distinguishes from siblings like 'get_index' or 'recompute_audit' by focusing on verification with provenance.

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 mentions a use case ('Use to cite a FLOPS index with provenance') but lacks comparison with alternatives or when-not-to-use. No explicit guidance on when to choose this over siblings like 'get_index' or 'list_indices'.

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