Skip to main content
Glama

Inspect and price a task or tool

capability_inspect
Read-onlyIdempotent

Read one task or provider tool from Ahel's catalog by its id: its exact inputs (Ahel's own contract, or the published reference input when Ahel has none), its status and exact reason, Ahel's price per provider (Unknown when Ahel has no rate), for a temporarily unavailable item the market prices seen elsewhere, for comparison, and the exact run_capability call when it can run. With arguments it also prices that exact run before anything runs: Ahel's quote, the most it may cost, the amount a run would reserve and whether the balance covers it; nothing is reserved, charged or started. With rows or rows_text (up to 100, for people.email.find or companies.register.search or companies.emails.from_website) it quotes a whole list instead: rows, rows that can run, each row's price and the most one row and the list may cost, the balance against it, and what each row that cannot run is missing. Free; changes nothing. NOT for: finding ids, which is capability_search, or running it, which is run_capability.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "capability_inspect"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesA task id or tool id from capability_search.
rowsNoA list for people.email.find or companies.register.search or companies.emails.from_website: 1 to 100 rows, each run once as its own run with its own exact cost. One object per row, such as {"name": "Patrick Collison", "domain": "stripe.com"} or {"name": "Wise", "country": "GB"}.
argumentsNoOptional: the run's inputs, by name, to price that exact run (a quote only; nothing runs).
max_itemsNoWith arguments: most rows to price for, 1-100. Default 10.
rows_textNoA list for people.email.find or companies.register.search or companies.emails.from_website: 1 to 100 rows, each run once as its own run with its own exact cost. Instead of rows: paste up to 100 rows as text, one per line ("Patrick Collison, stripe.com"; "Wise, GB") or a CSV with a header row (name, domain, linkedin_url; name, country).
endpoint_idsNoWith arguments: price the run on these providers only (endpoint ids from this answer).
timeout_secondsNoWith arguments: longest the run may take, 1-180 seconds. Default: the provider's own (60, more for slow sources).
exclude_endpoint_idsNoWith arguments: price the run without these providers.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / rows_text / description
      Previous value: -"A list for people.email.find or companies.register.search or companies.emails.from_website: 1 to 100 rows, each run once as its own run with its own exact cost. Instead of rows: paste up to 100 rows as text, one per line (\"Patrick Collison, stripe.com\"; \"Wise, GB\") or a CSV with a header row (name, domain, linkedin_url; name, country), read as Ahel's Run a list page reads a paste."New value: +"A list for people.email.find or companies.register.search or companies.emails.from_website: 1 to 100 rows, each run once as its own run with its own exact cost. Instead of rows: paste up to 100 rows as text, one per line (\"Patrick Collison, stripe.com\"; \"Wise, GB\") or a CSV with a header row (name, domain, linkedin_url; name, country)."
  2. Changed2 schema fields changed
    • changedInput schema / properties / rows / description
      Previous value: -"A list for people.email.find or companies.register.search: 1 to 100 rows, each run once as its own run with its own exact cost. One object per row, such as {\"name\": \"Patrick Collison\", \"domain\": \"stripe.com\"} or {\"name\": \"Wise\", \"country\": \"GB\"}."New value: +"A list for people.email.find or companies.register.search or companies.emails.from_website: 1 to 100 rows, each run once as its own run with its own exact cost. One object per row, such as {\"name\": \"Patrick Collison\", \"domain\": \"stripe.com\"} or {\"name\": \"Wise\", \"country\": \"GB\"}."
    • changedInput schema / properties / rows_text / description
      Previous value: -"A list for people.email.find or companies.register.search: 1 to 100 rows, each run once as its own run with its own exact cost. Instead of rows: paste up to 100 rows as text, one per line (\"Patrick Collison, stripe.com\"; \"Wise, GB\") or a CSV with a header row (name, domain, linkedin_url; name, country), read as Ahel's Run a list page reads a paste."New value: +"A list for people.email.find or companies.register.search or companies.emails.from_website: 1 to 100 rows, each run once as its own run with its own exact cost. Instead of rows: paste up to 100 rows as text, one per line (\"Patrick Collison, stripe.com\"; \"Wise, GB\") or a CSV with a header row (name, domain, linkedin_url; name, country), read as Ahel's Run a list page reads a paste."
  3. Changed2 schema fields changed
    • addedInput schema / properties / rows
      Added value: +{
      +  "description": "A list for people.email.find or companies.register.search: 1 to 100 rows, each run once as its own run with its own exact cost. One object per row, such as {\"name\": \"Patrick Collison\", \"domain\": \"stripe.com\"} or {\"name\": \"Wise\", \"country\": \"GB\"}.",
      +  "items": {
      +    "type": "object"
      +  },
      +  "maxItems": 100,
      +  "minItems": 1,
      +  "type": "array"
      +}
    • addedInput schema / properties / rows_text
      Added value: +{
      +  "description": "A list for people.email.find or companies.register.search: 1 to 100 rows, each run once as its own run with its own exact cost. Instead of rows: paste up to 100 rows as text, one per line (\"Patrick Collison, stripe.com\"; \"Wise, GB\") or a CSV with a header row (name, domain, linkedin_url; name, country), read as Ahel's Run a list page reads a paste.",
      +  "type": "string"
      +}
  4. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, yet the description still adds meaningful behavior: it is free, nothing is reserved, charged or started, and unknown rates surface as 'Unknown'. That is real value beyond the hints, though 'Free; changes nothing' partly restates the read-only annotation.

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

Conciseness3/5

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

It is front-loaded with the core read action, but the middle is a single dense run-on sentence with nested clauses about pricing, reservation, and list quoting. The information is useful, yet the packaging makes it harder to scan than it needs to be.

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

Completeness5/5

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

For an 8-parameter tool with no output schema and nested objects, the description fully covers what a caller needs: both operating modes, what each return includes, cost implications, and the boundaries against siblings. Nothing essential to a correct invocation is missing.

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

Parameters3/5

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 and the schema already documents defaults, ranges, and row formats. The description adds context on which tools accept rows and that arguments/endpoint_ids/timeout_seconds are pricing modifiers only, but it does not supply syntax or format details beyond what the schema already provides.

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 opens with a specific verb and resource ('Read one task or provider tool from Ahel's catalog by its id') and enumerates exactly what comes back: inputs, status, per-provider price, market comparison, and the run call. A closing 'NOT for' clause explicitly separates it from capability_search and run_capability, so an agent can distinguish it from every sibling without opening a schema.

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

Usage Guidelines5/5

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

It states the three usage modes with their triggers: bare id for inspection, 'arguments' to price a single run before executing, and 'rows'/'rows_text' to quote a whole list. It names the excluded jobs by tool name ('finding ids, which is capability_search, or running it, which is run_capability'), leaving almost nothing to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.