AgentShare — Solana DeFi Intelligence (Meteora DLMM) MCP

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

Annotations already declare readOnly/idempotent/openWorld, so the bar is lowered, and the description still adds real context: the ranking heuristic used, auth mechanisms (X-API-Key / Bearer / x402 settlement after HTTP 402), and the signup requirement. It stops short of describing the returned offer shape or what happens when no trusted in-stock listing exists. The trailing meteora_brief pricing sentence applies to a different tool and slightly muddies the billing picture for this one.

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 purpose and the routing rule are front-loaded and efficient, but the closing block is boilerplate auth/signup/pricing text, including a sentence about meteora_brief pricing that is irrelevant to this tool. That material dilutes a description that would otherwise be two tight sentences.

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 single-parameter lookup, the description covers purpose, selection logic, and invocation requirements adequately. With no output schema, however, it gives no indication of what an "offer" contains (price, seller, listing URL, freshness) or how a null/no-offer result is signaled, leaving a meaningful gap for a recommendation 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?

Only one parameter and schema coverage is 100%, with the schema already giving a concrete example format ("product name + model or distinguishing keywords"). The description reframes it as a "product intent" but adds no syntax, matching behavior, or disambiguation guidance beyond the schema. Baseline 3 applies when the schema carries the 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?

States a specific verb and resource ("Return the single best current offer") and immediately defines the selection rule ("lowest price among in-stock listings the API trusts"). It also names the sibling it is not (search_products) for comparison use cases, so an agent can distinguish it without opening either 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?

Explicit triggering conditions are given ("user asks where to buy something cheapest, 'best deal', or one clear recommendation") plus an explicit exclusion routing to search_products for side-by-side comparison. This is the when/when-not/alternative pattern in full.

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, idempotentHint and openWorldHint, so safety is covered; the description still adds real operational context—required auth headers, x402 settlement after HTTP 402, and the fact that price is dynamically quoted rather than fixed. The 'never hard-code' pricing warning is a genuine behavioral trait. It loses a point only because the pricing detail drifts toward a different tool (meteora_brief) rather than this tool's own response 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?

Purpose and usage are well front-loaded, but the tail is padded with material unrelated to selecting this tool: a signup URL, a pricing-page link, and a dynamic-pricing paragraph about meteora_brief's $0.01–$0.30 range and PAYMENT-REQUIRED headers. That is a large fraction of the text that does not help an agent decide or invoke this two-parameter tool.

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-only, open-world lookup with no output schema and full annotation coverage, the description supplies what is otherwise missing: when to use it, the cap semantics, and the auth/payment prerequisites that would cause a call to fail. Only the omission of the shape of the returned offer list keeps it from a 5.

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 both parameters are documented in the schema itself, including the exclusiveMinimum on max_price. The description's note to pass max_price 'in the same numeric unit the deployed API expects' restates the schema's 'same numeric scale as the API's pricing fields' with only a pointer to docs, adding minimal new meaning. 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 opens with a specific verb and resource ('Find the best offer for a product query') plus the defining constraint ('maximum price ceiling'), which is exactly what separates it from the sibling best_offer and search_products. An agent can identify the tool's job without reading 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?

It gives explicit trigger phrases ('under $X', 'below …', 'no more than …') for when to use it, and an explicit exclusion plus named alternatives ('Do not use for open-ended comparison without a cap—use search_products or best_offer'). This is the full when/when-not/alternative triad.

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 read-only/idempotent/closed-world, but the description adds substantial context beyond them: the probe is roughly a day stale, the tool does not perform live checks, the full enumerated value set, and a precise definition of when schema_status is 'breaking'. It also discloses the auth scheme (API key / Bearer, x402 settlement after HTTP 402), which no annotation conveys.

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 sentences are front-loaded and dense with useful facts, but the trailing auth, signup URL, and especially the meteora_brief dynamic-pricing sentence are boilerplate about a different tool and do not earn their place here. Roughly a third of the text is off-topic for check_health.

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 carries the return-value burden and does so by naming all three returned fields and enumerating the health_status values. The remaining gap is the both-optional parameter contract, which is left unexplained.

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, but the description adds meaning the schema does not: it frames record_id and mcp_url as alternative lookup keys and names search_listing as the source of record_id. It does not resolve precedence between them, which keeps it from a 5.

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 ('Read one verified listing's stored health_status, last_checked_at, and schema_status') and enumerates exactly what comes back. The word 'stored' plus 'This tool never pings the MCP' separates it cleanly from search_listing and from any live-probe behavior a sibling might imply.

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 a clear entry path ('Pass record_id from search_listing, or the exact mcp_url') and an explicit exclusion ('This tool never pings the MCP. Connect to mcp_url yourself'). It falls short of 5 because it never says which of the two optional parameters to prefer, nor what happens when neither is supplied and zero parameters are required.

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 only cover readOnly/idempotent/openWorld; the description adds the real operational context: auth headers (X-API-Key / Bearer), x402 settle-after-402 dual auth, and the warning that pricing is dynamic and must be read from PAYMENT-REQUIRED / meta.billing.price_usd_live rather than hard-coded. Missing rate-limit or failure-mode notes, so not a full 5.

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 and dense, but the tail is a run-on mixing auth, a signup URL, and a note about dynamic pricing on meteora_brief — a different tool — which dilutes the sentence for this tool. Useful material, poorly scoped to the tool being described.

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 should carry the return shape; it names the agentshare.price.v1 listings envelope and one billing field but never describes the listings returned or how best_offer's single pick is presented. Adequate for auth and mode selection, thin on results.

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 enum/default/description for mode, limit, currency and max_price_usd are already documented in the schema. The description's mode and budget guidance largely restates schema text and does not resolve the name/unit mismatch on max_price_usd (named _usd but described as being in VND or USD).

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 (quote) plus resource (commerce listings) and the mechanism (wraps search or best_offer into the agentshare.price.v1 envelope). An agent can distinguish it from search_listing / best_offer_under_budget as a wrapper layer, though the 'ACP/Virtuals-friendly' framing assumes jargon the agent may not share.

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?

Explicit routing by mode: mode=search for multiple listings, mode=best_offer for a single cheapest pick, max_price_usd with mode=best_offer for budget-constrained buyers. It does not say when to call this wrapper instead of the sibling best_offer or best_offer_under_budget directly, which is the main ambiguity left.

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, idempotentHint, and openWorldHint, so the description only needs to add value beyond those. It adds auth and latency hints, but also includes irrelevant details about REST formats, commerce fields, signup, and dynamic pricing on a sibling tool (meteora_brief), which dilute the useful context.

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 overly long and padded with information unrelated to this tool (REST format options, commerce fields, x402 auth flow, signup URL, and pricing on meteora_brief). The core purpose is front-loaded, but the trailing irrelevancies reduce conciseness significantly.

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 ranking tool with no output schema and three well-described parameters, the description covers the essential purpose, usage context, and parameter hints. However, the conflicting limit guidance could lead to suboptimal calls, keeping it from a perfect score.

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 the parameters. The description adds a conflicting limit recommendation ('prefer small limit (3–5)') while the schema says 'prefer 5–10', which could confuse an agent. No other parameter meaning is added beyond 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 states a specific verb (rank) and resource (DEX protocols) with clear sorting options (24h volume or 1d change). It also distinguishes itself from siblings by suggesting it's for macro trend discovery before deeper pool analysis.

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 provides clear context ('Use for macro DEX trend discovery before deeper pool analysis') but does not explicitly name alternative tools or state when not to use it. The chain filter examples and limit preference give some usage 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 cover readOnlyHint/idempotentHint, and the description adds genuinely new operational context: auth headers on /mcp, REST dual-auth with x402 settlement after HTTP 402, and a latency-driven preference for small limits. The 'Read-only' restatement is redundant, and the trailing pricing sentence concerns meteora_brief rather than this tool, so it is not a 5.

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 first two sentences are well front-loaded and earn their place, but the remainder is generic cross-tool boilerplate about REST content negotiation, signup URLs, and dynamic pricing on meteora_brief — a different tool entirely. Roughly half the text is unrelated to selecting or calling dex_top_movers.

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, zero-required-parameter list tool with full schema coverage and no output schema, the definition supplies the ranking logic, the volume floor, latency advice, and auth/payment paths. An agent has everything needed to call it correctly on first attempt.

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 documented chain/limit/min_volume_24h_usd fields already carry their own semantics. The description still adds value beyond the schema by advising a small limit (3–5) to control latency, which the schema's default of 10 and max of 50 would not suggest. The chain parameter is never contextualized in prose.

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 opening sentence gives a specific verb and resource plus the ranking rule ('largest absolute 1d volume change %') and a filter ('above a minimum 24h volume'), which is precise enough to distinguish this from dex_overview or solana_dex_brief. It does not name or contrast any sibling explicitly, so it stops short of 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 to prioritize venues with unusual flow' states the intended decision context, and 'prefer small limit (3–5)' gives concrete invocation guidance for latency. There is no statement of when NOT to use it or which sibling to pick for the alternative (e.g., a full per-chain overview), so no explicit alternatives are offered.

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?

Goes well beyond the readOnly/idempotent annotations: discloses dynamic x402 pricing with a $0.01–$0.30 USDC range and where the exact live quote appears, both auth paths (X-API-Key / Bearer, or settle x402 after HTTP 402), and a latency/token cost hint ('prefer small limit (3–5)'). It also documents alternate response encodings (Accept header, ?format=compact, ?fields=, ?simple=true), which no annotation conveys.

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?

Purpose and output fields are correctly front-loaded, but the paragraph is overstuffed with semicolon-chained clauses and repeats the x402 dynamic-pricing statement almost verbatim twice. The signup URL and REST encoding notes are useful, yet the duplication costs space that could have gone to distinguishing sibling tools.

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 12-parameter, no-output-schema tool, the description closes the important gaps: it enumerates the returned fields, explains the kind modes and the recommended hunt recipe, and covers auth, pricing, and compaction. An agent can invoke it correctly and interpret the response without opening further docs.

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 already 100%, so the baseline is 3; the description earns extra by explaining what compact actually abbreviates ('keeps v5m/v1h/vu/mom') and by showing a validated parameter constellation for hunt mode (kind, window, sort_by, min_tvl, limit, full). It still leaves honor_sort, page_size, and filter_by entirely to the schema, so it is not a complete semantic layer.

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 concrete verb and resource ('rank pools by fee/TVL, fees, volume, APR, or TVL') plus the output contract (verdict SAFE/CAUTION/AVOID, risk_score, momentum_score, fee_velocity, bin_step_risk_tier, volume buckets, flags, citations). This is far more specific than the bare title 'Meteora DLMM pool brief' and separates it from the generic solana_dex_brief sibling.

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 an explicit when-to-use rule ('kind=hunt_pools for mid-risk hunt (SAFE+CAUTION; AVOID only with real volume_5m)') and an explicit when-NOT ('do NOT use top_pools_safe as hunt universe'), plus a concrete recommended call shape. However, the routing guidance is all at the parameter-mode level; no sibling tool is named as an alternative or exclusion, so an agent still has to infer when to pick meteora_pool_detail or solana_dex_brief instead.

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 read-only/idempotent/open-world, yet the description still adds real behavioral context: range_health_status=unavailable rather than a fake 0, ohlcv_status=unsupported, and the auth model (X-API-Key/Bearer or x402 settlement after HTTP 402). It loses a point because 'prefer small limit (3–5)' refers to a parameter that does not exist on this tool, and the pricing paragraph describes meteora_brief rather than this call.

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 output-field inventory is correctly front-loaded and dense, but the trailing block mixes signup URLs, x402 settlement mechanics, and dynamic pricing about a different tool (meteora_brief), which dilutes the signal. The nonexistent 'limit' advice is wasted text an agent cannot act on.

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 does the heavy lifting by naming the returned fields and their degraded-value semantics, which is what an agent needs to interpret results. Remaining gaps are minor: no note on error responses for an invalid pool_address beyond the schema's length bounds.

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, but the description adds meaning the schema lacks: compact maps to REST ?format=compact or the Accept vendor media type, and commerce surfaces accept ?fields= and ?simple=true. It also explains the derivation behind band_bps (± half-width around active_bin_id) and that window governs fee_velocity via meta.window.

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?

Names the resource precisely (Meteora DLMM pool detail v2) and enumerates the concrete output fields — price_unit, mints, range_health, active_bin_id, fee ratios — so an agent knows exactly what it gets back. It is differentiated from the sibling meteora_brief by the sequencing note, though the wording is a noun phrase rather than an explicit verb like 'fetch'.

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 after meteora_brief when you have pool_address' gives an explicit prerequisite and predecessor tool, which is strong guidance. It also advises compact=true for abbreviated keys and small limits, but never states when NOT to use it or what to use instead for other pool data.

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 read-only, idempotent, open-world behavior, and the description adds meaningful operational context about API-key/Bearer auth and x402 settlement after HTTP 402. However, the pricing sentence refers to meteora_brief rather than this tool, adding some noise and not fully clarifying product_detail's own billing/return 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?

Purpose and usage are front-loaded, but the description spends substantial space on auth/signup/payment details, and the final dynamic-pricing note for meteora_brief is not clearly relevant to product_detail. That clutter weakens an otherwise efficient definition.

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 description identifies the return contents (full details and per-source prices) and covers auth/payment prerequisites. It stops short of describing the return shape or error behavior, but the core calling information is present.

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 product_id, currency, and include_analysis are already documented. The description reinforces that product_id comes from a prior search_products result but adds little syntax or meaning beyond 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 states a specific verb and resource: return full product details and per-source prices for a numeric product_id. It also distinguishes this from search_products by saying it is for a known id and not for open-ended search.

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 use cases—drilling into one listing, specs, history context, affiliate links—and an explicit exclusion: not for open-ended search. The link to a prior search_products result makes the intended workflow 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?

Goes well beyond the annotations by disclosing human review, spam gates (auth, rate limits, mandatory schema, paid stake ~$0.05), both auth paths, and the non-email nature of contact_hint. The final sentence about meteora_brief dynamic pricing is off-target for this tool and adds noise rather than behavioral clarity.

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 purpose and required fields are front-loaded effectively, but the description is bloated with signup URL, x402 settlement mechanics, and a pricing paragraph about meteora_brief that has nothing to do with this tool. Several clauses do not earn their 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 should say what happens after submission; it does (human review, admin web follow-up, not emailed, spam-gated). It stops short of describing what the caller gets back (request ID, status, acceptance criteria), leaving a modest 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 100%, so the baseline is 3. The description lists required and optional fields and adds the 'willingness to pay per call if we ship it' framing for budget_usd, but repeats what the schema already documents rather than adding format or content-depth guidance.

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 ('submit a structured capability gap for human review') plus the exact trigger condition ('when fixed MCP tools are insufficient'). No sibling tool in the list does anything similar, and the description makes that distinction 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?

Gives a clear conditional trigger ('when fixed MCP tools are insufficient') and an explicit exclusion ('does NOT generate or execute new code'), which prevents the most likely misuse. It never names specific sibling tools to try first, though the 'nearest_existing_tool' parameter hints at that workflow.

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 and idempotentHint, but the description adds real value beyond them: health_status is *stored*, not live; the tool does not ping or proxy; sponsored/Featured rows are sorted first and marked; plus auth modes (X-API-Key, Bearer, x402 settle after 402). These are behavioral facts no annotation conveys.

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 is well front-loaded (purpose, returns, alternatives, read-only caveat). But the trailing auth/signup/x402 block and especially the meteora_brief dynamic-pricing sentence are irrelevant to searching listings and bloat the definition with boilerplate that does not help select or invoke this tool.

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 3-parameter read-only search with no output schema, the description covers return contents, result cap, sorting/sponsorship, freshness caveat, and auth/payment paths. An agent has everything needed to call it and interpret the response 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% and all three parameters are self-documented, so the baseline of 3 applies. The description repeats the 10-row cap and sponsored-first ordering that the schema's own limit field already states, and adds nothing about keyword matching or category slug 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?

States a specific verb and resource ('Search the curated MCP registry') and enumerates the return fields (name, short description, mcp_url, health_status) plus the 10-row cap, so the agent knows exactly what comes back. It differentiates itself from check_health and rank_tools_for_task, but never distinguishes itself from the sibling search_products, which is the most likely confusion.

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?

Explicit routing: use check_health when last_checked_at is needed, connect to mcp_url yourself, and call rank_tools_for_task before paying a listing. Each alternative is named with the condition that selects it, which is exactly what usage guidance should do.

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 readOnly/idempotent/openWorld, and the description goes further with token/latency guidance, compact output negotiation, and concrete auth paths (X-API-Key / Bearer / x402 settlement). It loses a point for the trailing dynamic-pricing paragraph aimed at meteora_brief, which is a different tool and adds noise rather than behavioral insight about this search.

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?

Purpose, alternatives, and domain scope are correctly front-loaded, but the tail drifts into transport/auth/signup/pricing documentation, including a meteora_brief pricing rule that has nothing to do with search_products. Roughly a third of the text is operational boilerplate rather than selection-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?

With no output schema, the description does supply the return shape (prices, sources, freshness) and the auth/payment requirements needed to actually call it. Pagination and failure behavior are not covered, which is the main remaining gap for a search endpoint.

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 still adds operational meaning by advising limit 3–5 for token savings and explaining simple=true as a minimal-field preset, plus noting queries may be free-text in any language. It does not explain what the limit cap of 50 means in practice or how ordering works.

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?

Opens with a specific verb and resource ("Search connected marketplaces") and states what comes back ("structured offers (prices, sources, freshness)"). It also carves out the boundary against the sibling best_offer in the same sentence, so an agent can pick between them without opening either 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?

Explicitly names the when-to-use case (compare options, browse multiple listings, explore a category/model) and the when-not-to-use case (single definitive cheapest pick → use best_offer). Domain scope (robotics parts, drone batteries, AI hardware) and free-text/any-language input are also given.

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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile needs no explanation. The description adds real value beyond them by disclosing the auth split: the underlying REST call needs no API key, but the MCP endpoint requires X-API-Key or Bearer per site policy. It doesn't describe the shape of the returned metadata, which is the only behavioral gap.

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?

There are three sentences, and the primary payload comes first: the return contents and endpoint, followed by auth context. The detail about X-API-Key versus Bearer is borderline operational trivia, but it is genuinely load-bearing for an agent deciding whether this call will succeed.

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 parameterless, read-only introspection tool with no output schema, the description supplies the payload contents, the precondition, and the auth requirements. An agent could call it correctly from this text alone. The only missing piece is a hint about the return format, which is minor here.

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?

This tool has zero parameters, so the schema already provides everything an agent needs on that dimension; the baseline of 4 applies. The description correctly says nothing about inputs, and nothing it does say misleads about them.

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 and resource: it returns API capabilities, rate limits, and integration hints from GET /api/v1/meta. That is far more concrete than the bare name 'service_meta'. It doesn't explicitly differentiate itself from the sibling request_capability, which an agent could plausibly confuse it with.

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 context: 'Use after you are authenticated to MCP for onboarding and capability checks.' That tells the agent both the precondition and the intent. It names no exclusions or alternatives, so it stops short of full when/when-not 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 cover readOnly/idempotent/openWorld, but the description goes further by disclosing that the endpoint is public read-only, that meta.billing is x402-ready, that /mcp requires X-API-Key or Bearer auth and REST can settle x402 after a 402, and that live pricing must be read from meta.billing rather than hard-coded. That is genuine operational detail beyond the annotations. It is undercut by mixing in dynamic-pricing guidance for meteora_brief, a different tool, which muddies rather than clarifies this tool's 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 purpose and sibling routing are front-loaded correctly, but the body is a dense run-on mixing REST MIME types, dual-auth mechanics, a signup URL, and dynamic pricing that belongs to another tool. Several clauses (the vnd.agentshare.compact+json media type, the pricing URL, the meteora_brief price range) do not earn their place in this tool's description.

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 three-parameter, optional-argument read tool with full schema coverage and no output schema, the definition covers what the data is, where it comes from, and how to reach it. What it never describes is the return shape — what a 'verdict/risk envelope' actually contains or how highlights_only changes the response — which is the main omission.

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 already documents limit, compact and highlights_only — baseline 3. The description adds little: it repeats the limit guidance but with a conflicting range ('prefer small limit (3–5)' vs the schema's 'prefer 5–10' and default of 15), and its ?format / ?fields / ?simple notes describe REST query strings rather than the MCP parameters.

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 the resource and scope precisely: protocol-level Solana DEX metrics (24h volume and change) sourced from DefiLlama, plus a verdict/risk envelope. It explicitly carves out the pool-level case and names the two Meteora siblings, so an agent can distinguish it from meteora_brief and meteora_pool_detail. The only weakness is that there is no crisp leading verb — the purpose statement is a noun phrase competing with billing/auth boilerplate.

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 explicit routing guidance for the closest Meteora alternatives ('For pool-level Meteora DLMM use meteora_brief or meteora_pool_detail') and a latency tip ('prefer small limit'). It says nothing about when to choose this over its other DEX siblings such as dex_overview or dex_top_movers, which are arguably equally close alternatives, leaving a real gap in the when-to-use story.

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