Electra Index

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

Annotations only cover readOnlyHint and openWorldHint; the description adds genuinely new behavioral context by disclosing the ranking basis (name match, breadth, hosted, open source, freshness) and explicitly that payment never influences ranking. That anti-bias disclosure is exactly the kind of trait an agent cannot infer from structured fields.

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 tight sentences with no filler; the core purpose and the use_case examples are front-loaded and the fallback-call instruction closes cleanly. Minor density cost from the parenthetical example list, but it earns its place as sample inputs.

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

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

For a read-only lookup with no output schema, the agent gets purpose, ranking methodology, sample use cases, and the discoverability fallback. The remaining gap is result-shaping: nothing explains what limit does or roughly how many servers come back.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It does clarify use_case by example and explains the omitted-parameter behavior, which is valuable, but the 'limit' parameter (default 10, max 15) is never mentioned in the description or 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?

States a specific action and resource: ranked MCP servers, scoped by use case, with concrete example domains. It is distinguishable in spirit from search_mcp_servers (curated ranking vs lookup), but it never names a sibling tool, so the differentiation is left implicit.

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

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

Gives one concrete calling pattern ('call without use_case to get the list of use cases'), which is real usage guidance. However, it never says when to prefer this over search_mcp_servers or get_mcp_server, nor what input shape a use_case expects.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is lower. The description adds genuinely useful behavior beyond them: the data is scraped from an official pricing page and each plan carries a last-confirmed date, implicitly warning the agent that the values are point-in-time and may be stale.

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 short sentences: the first delivers the return content and freshness caveat, the second delivers the input sourcing instruction. Nothing is padded and the important content 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?

With no output schema, the description usefully discloses the return structure (plans plus confirmation dates) and the input provenance. The remaining gap is error/empty behavior for agents lacking a pricing page, which is minor for a single-parameter read tool.

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

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

The single slug parameter has 0% schema description coverage, so the description must carry the meaning. It does so by stating where the slug originates (search_ai_agents) and that it identifies an AI agent, which is the key semantics an agent needs to populate it correctly.

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

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

The description names the resource (an AI agent's current pricing plans), the source (official pricing page), and the payload shape (each plan with a last-confirmed date). It also names the sibling that supplies the required identifier (search_ai_agents), which separates it from the search/get_mcp_server tools. It stops short of an explicit verb phrase, but the name plus content description make the purpose unambiguous.

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

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

It gives an explicit prerequisite: the slug must come from search_ai_agents, which tells the agent exactly when and how to use this tool in a chain. There is no when-not guidance or statement of what happens for agents without a pricing page, so it is clear context rather than full routing guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds useful detail about what is returned, including endpoints, header names only, install packages, environment variables, live check result, tools, and capabilities. It does not discuss error behavior or rate limits, but it meaningfully enriches the annotation coverage.

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

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

The description is front-loaded with the core purpose and then lists the returned information efficiently, followed by a concise routing sentence. There is 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 no output schema, the description appropriately enumerates the returned fields and is sufficient for an agent to understand the response content. Minor gaps remain around invalid-slug behavior and exact slug format, but the definition is otherwise complete for a simple read tool.

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

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

The schema has only one parameter and 0% description coverage, so the description must carry the semantic burden. It does explain that slug comes from search_mcp_servers, which is useful, but it does not specify the slug format or validation behavior.

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 frames this as a retrieval tool for one MCP server and enumerates the detailed record it returns. It distinguishes itself from search_mcp_servers by requiring a slug from that search, though it does not explicitly contrast with get_mcp_server_history.

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 path: call search_mcp_servers first, then use the returned slug here. It does not state when-not-to-use or explain the alternative history tool, but the primary context is clear.

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

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

Annotations cover only readOnlyHint and openWorldHint; the description adds the critical non-obvious trait that this is a paid call (x402, USDC on Base, $0.01 or 1 credit), which an agent must know before invoking. It also describes the returned content in lieu of an output schema, though it omits rate limits and whether a large 'days' window is bounded in practice.

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

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

Front-loaded with the payload contents in the first sentence, followed by usage guidance and pricing. Three sentences, no filler, though the pricing clause is somewhat verbose and could be tightened.

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 two-parameter read tool with no output schema, the description adequately covers what is returned and the payment requirement. It is nevertheless incomplete on the parameter side (slug meaning, days window semantics and its 365-day cap), which is exactly what an agent needs to call it correctly.

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

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

Schema description coverage is 0% and the description never explains either parameter: it does not say that 'slug' identifies the MCP server nor that 'days' sets the lookback window for the checks. The schema supplies only type/default/min/max, so the description fails to compensate for the coverage 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?

Specific verb+resource: 'Timestamped history of Electra Index's live checks for one MCP server', with an enumeration of what the history contains (check results, status transitions, answer rate, tool count, version changes). The time-series framing implicitly separates it from get_mcp_server, but no sibling is named or contrasted explicitly.

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

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

'Use it before relying on a server in production' gives a clear triggering context for the tool. There is no when-not guidance and no named alternative (e.g. get_mcp_server for current status only), so it falls short of the explicit routing a 5 requires.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real context beyond that: it enumerates what each result carries (Agent Score 0-100, starting monthly price, free plan, themes, page) and notes the data is public-only. It does not explain limit/pagination 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?

A single front-loaded sentence stating the resource, source, and returned fields, followed by compact query examples. Dense but every clause (fields, examples) carries information; 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 no output schema, the description usefully enumerates the result fields, which is the key missing structured information. The remaining gap is limit/pagination semantics and any explicit routing to sibling tools, but for a two-parameter read-only search this is nearly 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 0%, so the description must compensate. It adds meaning for query by giving concrete example strings, but says nothing about the limit parameter's default (5), range (1-10), or that it caps result count.

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 gives a specific verb (Search) and resource (ready-made AI agents/products) plus the source (Electra Index), which cleanly separates it from the sibling search_mcp_servers. An agent can tell what it returns without opening the schema.

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

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

Usage is only implied: the example queries ('sales outreach', 'customer support', 'coding') suggest the kind of intent this tool serves. There is no explicit when-to-use vs when-not, and no sibling such as search_mcp_servers or get_agent_pricing is named as an alternative.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real context beyond that: provenance ('Official MCP Registry, tested live by Electra Index') and the specific fields returned, including live check status, which tells the agent results are freshness-verified.

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

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

Two tight sentences: purpose and source first, return fields second, usage cue last. Every clause carries information and nothing is padded.

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

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

With no output schema, the description helpfully enumerates the returned fields, and it covers purpose, source, and usage. Remaining gaps are minor: no differentiation from the sibling search/curation tools and no hint about result-count/pagination behavior tied to limit.

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 67%: query and hosted_only are described in the schema, but limit (default 5, max 10) is not. The description adds no parameter-level detail such as query phrasing tips or how limit affects results, so the schema is doing essentially all the work.

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

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

States a specific verb and resource ('Search the Electra Index catalogue of MCP servers') and names the underlying data source, so the agent knows exactly what corpus is being queried. It does not differentiate itself from close siblings like best_mcp_servers_for or get_mcp_server, which keeps it from a 5.

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

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

'Use it to find a server for a task' with concrete example queries ('web scraping', 'invoices', 'postgres') gives clear usage context and shows the expected query style. No when-not condition or explicit alternative (e.g. best_mcp_servers_for for curated picks) is named, 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.