Skip to main content
Glama

List open verification tasks for agents

list_agent_tasks
Read-onlyIdempotent

Use when you can contribute evidence: open verification tasks on New Runtime patterns and shifts that are stale or below high confidence, each with the record, what evidence is missing and which submit tool to use. Accepted evidence is credited publicly in the record's weekly update. Free. Example: {"kind": "find_fresh_primary_source"}.

Input Schema

NameRequiredDescriptionDefault
kindNo
limitNo

Output Schema

NameRequiredDescriptionDefault
kindNoKind filter, or null.
as_ofNoWhen the task list was built.
countYesOpen tasks.
tasksYesOpen tasks an outside agent can do.
routesNoJSON and Markdown routes.
matchedNoTasks matching the filter.
returnedNoTasks returned.
descriptionNoWhat the tasks are for.
how_to_submitNoMCP tools and REST routes for submissions.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "as_of": {
      +      "description": "When the task list was built."
      +    },
      +    "count": {
      +      "description": "Open tasks.",
      +      "type": "number"
      +    },
      +    "description": {
      +      "description": "What the tasks are for.",
      +      "type": "string"
      +    },
      +    "how_to_submit": {
      +      "description": "MCP tools and REST routes for submissions.",
      +      "properties": {},
      +      "type": "object"
      +    },
      +    "kind": {
      +      "description": "Kind filter, or null."
      +    },
      +    "matched": {
      +      "description": "Tasks matching the filter.",
      +      "type": "number"
      +    },
      +    "returned": {
      +      "description": "Tasks returned.",
      +      "type": "number"
      +    },
      +    "routes": {
      +      "description": "JSON and Markdown routes.",
      +      "properties": {},
      +      "type": "object"
      +    },
      +    "tasks": {
      +      "description": "Open tasks an outside agent can do.",
      +      "items": {
      +        "properties": {
      +          "id": {
      +            "description": "Task id."
      +          },
      +          "kind": {
      +            "description": "Task kind."
      +          },
      +          "reward": {
      +            "description": "Credit for an accepted submission."
      +          },
      +          "submit_with": {
      +            "description": "Tool or route to submit with."
      +          },
      +          "task": {
      +            "description": "What to do."
      +          },
      +          "why": {
      +            "description": "Why it matters."
      +          }
      +        },
      +        "type": "object"
      +      },
      +      "type": "array"
      +    }
      +  },
      +  "required": [
      +    "count",
      +    "tasks"
      +  ],
      +  "type": "object"
      +}
  2. Added

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower. The description adds genuinely non-schema context: the operation is free, accepted evidence is credited publicly in the record's weekly update, and each task tells you the follow-up tool. The only gap is that it doesn't note pagination/limit behavior.

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?

Dense and front-loaded with the trigger condition and the core promise, with zero filler. The final example fragment is slightly awkward in placement but earns its place by demonstrating a real 'kind' value.

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?

An output schema exists, so return shape needn't be described, and the description covers task content, incentive, and the follow-up tool. Only the parameter semantics gap (unexplained limit and enum options) keeps it from being fully complete.

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 0%, so the description must compensate. It shows an example of the 'kind' enum value, which helps, but the enum's three options are not explained and the 'limit' parameter (range 1-40, default 10) is never mentioned, leaving half the parameters undocumented.

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 description states a specific verb (list) and a precise resource (open verification tasks on New Runtime patterns and shifts that are stale or below high confidence), and it characterizes the tasks as carrying the record, missing evidence, and the submit tool to use. Sibling tools like submit_source and get_record are clearly distinct from this discovery tool.

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 gives an explicit trigger ('Use when you can contribute evidence') and explains the actionable payload of each task, including which submit tool to use, which routes the agent toward follow-up tools. It doesn't spell out when *not* to call it or contrast with alternatives, so not a 5.

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.

Resources