Skip to main content
Glama

Extract classifier data

extract_classifier_data
Read-onlyIdempotent

Extract and parse binary RECOMMENDATION + CONFIDENCE classifier output from verification-tagged Inoreader Intelligence summaries; optionally scan population score distribution for audit candidates.

Instructions

Pull Inoreader Intelligence summaries for the four verification-tagged streams (read/worth-it, read/not-worth-it, audit/worth-it, audit/not-worth-it) and parse a binary RECOMMENDATION + CONFIDENCE classifier output from each. Optionally also scans a folder/window for the score distribution among unverified articles. The verified set is the labeled dataset for calibration analysis. The population scan is the candidate pool for audit recommendations. Costs 4-80 base Zone 1 requests for the verified set (4 streams, up to 20 pages each), plus up to population_pages if include_population=true; retries are extra. Preflights the maximum page budget plus a 25-request reserve against known quota. Missing streams fail rather than masquerading as complete data; cap flags disclose partial coverage. Reads existing summaries only: never starts paid Intelligence processing. Base costs exclude safe-read retries (up to 4 attempts, each counted); honor cached status/cooldown. Never blindly replay uncertain writes. See inoreader://usage for limits, URI examples and prompts.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

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

Input Schema

NameRequiredDescriptionDefault
refreshNoNo-op, retained for compatibility. Reads are not cached between calls.
prompt_nameNoInoreader Intelligence prompt_name to filter summaries by. If omitted, the parser scans all summaries on each article and uses the first that matches the RECOMMENDATION/CONFIDENCE format.
population_pagesNoPer-stream page cap for the population scan (default 30).
population_folderNoFolder name to limit the population scan to. If omitted, scans the full reading-list stream.
population_monthsNoWindow in months for the population scan (default 3).
include_populationNoAlso fetch a window of articles (with summaries=1) to characterize the population score distribution. Default false. Required for recommend_audit_articles downstream.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.1

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the read-only and idempotent annotations, the description discloses cost ranges, page-budget preflight against quota, retry behavior, cap flags for partial coverage, and failure semantics for missing streams. It also explains that cached status/cooldown must be honored and that reads never trigger paid processing. This is unusually rich behavioral context for a read-only extraction tool.

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

Conciseness4/5

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

The purpose and scope are front-loaded, and most sentences carry necessary operational detail about costs, preflight, and failure modes. The text is dense and includes at least one clause about never replaying uncertain writes that is not clearly relevant to a read-only extraction tool, but there is little outright fluff.

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

Completeness4/5

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

For a six-parameter, read-only extraction tool with no output schema, the description covers costs, quotas, failure behavior, partial coverage, and downstream use thoroughly. It does not describe the exact shape of the returned dataset or population distribution, but that is a relatively minor gap given how much operational context is supplied.

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

Parameters4/5

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

Schema coverage is 100%, so the schema already documents all six parameters. The description still adds meaning by tying include_population and population_pages to concrete request cost and to the downstream recommend_audit_articles workflow. The remaining parameter behavior is largely covered by the schema, but the cost/usage linkage is a useful supplement.

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 states a specific verb and resource: pull Inoreader Intelligence summaries for four verification-tagged streams and parse a binary RECOMMENDATION + CONFIDENCE classifier output. It also distinguishes the verified dataset from the optional population scan and ties each to a downstream purpose, so the agent can tell what this tool produces versus sibling analysis tools.

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?

It clearly explains when the verified set is used (labeled dataset for calibration analysis) and when the population scan is needed (candidate pool for audit recommendations, explicitly required for recommend_audit_articles downstream). It also states an important boundary: reads existing summaries only, never starts paid Intelligence processing. It does not explicitly name an alternative sibling tool for the analysis step, so the when-not/alternative guidance is strong but not complete.

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