inoreader-mcp

Recommend audit articles

recommend_audit_articles

Read-onlyIdempotent

Suggests a small batch of recommend-skip articles to audit by scoring bin uncertainty, decision-threshold proximity, and optional sparse audit coverage, excluding already audited items.

Instructions

Suggest a small batch of recommend-skip articles to read as audits. Scores candidates by bin uncertainty (CI width on the calibration curve), proximity to the decision threshold, and (optionally) sparse audit coverage. Extracts existing summaries once with include_population=true, then computes uncertainty locally (no second API scan). Base cost 4-80 Zone 1 verification pages plus up to population_pages (default 30, max 200); preflights the maximum plus a 25-request reserve. Never starts paid Intelligence processing. Already-audited articles are excluded. 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": "recommend_audit_articles"
  }
}

Input Schema

Name	Required	Description
`bins`	No	Bin count for calibration (default 10).
`feed`	No	Bias toward candidates from a specific feed (matches feed_title).
`count`	No	Number of audit candidates to return (default 10).
`refresh`	No
`prior_strength`	No	Beta prior strength (default 4).
`population_pages`	No	Page cap (default 30).
`population_folder`	No	Folder for the population scan.
`population_months`	No	Window in months (default 3).
`decision_threshold`	No	Score threshold for proximity weighting (default 50).
`prefer_low_audit_coverage`	No	Bias toward feeds with few existing audit tags (default false). Useful for spreading audit coverage across feeds.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.6.1Nov 3, 2026

TDQS

A3.9/5.0

Behavior5/5

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

With annotations already covering the read-only/safe profile, the description adds substantial behavior the annotations cannot express: a cost model of 4-80 Zone 1 pages plus up to population_pages, a preflight of the maximum plus a 25-request reserve, exclusion of already-audited articles, safe-read retry accounting, and an explicit guarantee that it never starts paid Intelligence processing.

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?

Purpose and scoring logic are front-loaded before the cost and safety clauses, and the density is appropriate for a complex tool. Some clauses (retry semantics, cooldown honoring, the usage-resource pointer) stack into a single long run-on stretch rather than being grouped by topic.

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 10-parameter, no-output-schema, open-world tool, the cost, safety, and exclusion behavior are unusually complete. The gap is the return payload: it says nothing about the shape or fields of the returned audit candidates, which matters for a recommendation tool with no output schema.

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 90%, so defaults, ranges, and most parameter meanings are already documented in the schema (bins, count, prior_strength, population_pages, decision_threshold, prefer_low_audit_coverage). The description adds only marginal meaning beyond that, mostly tying population_pages to the cost/preflight story; it does not explain how the scoring knobs interact.

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

Purpose4/5

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

The first sentence states a specific verb and resource ('Suggest a small batch of recommend-skip articles to read as audits') and the second explains the ranking criteria (bin uncertainty, threshold proximity, audit coverage). It is clearly distinct from siblings like analyze_classifier_calibration, though the domain jargon 'recommend-skip' is left unexplained.

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

Usage Guidelines3/5

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

Usage is implied by the audit framing and by hints like 'honor cached status/cooldown' and the prefer_low_audit_coverage note about spreading audit coverage. However, there is no explicit when-to-use versus analyze_classifier_calibration, and no stated preconditions or when-not conditions for calling it.

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