Skip to main content
Glama

flconsole — Upwork jobs

list_feeds

Read-only

List all the user's feeds: id, name, alerts (Telegram notifications on or off), paused, filters, plain-text summary, ai_filter, your agent_notes, and the limits for feeds with and without alerts. Call it to get a feed_id for find_jobs or any feed change. Read-only, no hourly quota.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description reinforces this with "Read-only." It adds useful operational context that is not in annotations: "no hourly quota," plus the returned feed attributes and limits.

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

Conciseness5/5

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

The description is front-loaded with the action and result fields, followed by a clear usage trigger and a short operational note. The field list is dense but purposeful, with no filler.

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?

With no output schema, the description appropriately enumerates the key returned fields, including id, name, alerts, paused, filters, summary, ai_filter, agent_notes, and limits. Combined with annotations and the zero-parameter schema, an agent has enough information to call it correctly.

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?

The tool takes zero parameters, so there is no parameter semantics gap; baseline 4 applies. The description does not need to explain inputs beyond the empty schema.

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?

States a specific verb and resource ("List all the user's feeds") and enumerates the returned fields, making the tool's scope precise. It also distinguishes itself from nearby tools by naming find_jobs and general feed changes as follow-up consumers.

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?

Explicitly says when to call it: to obtain a feed_id for find_jobs or any feed change. It does not enumerate when not to use it or name every alternative, but the intended usage context is clear.

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.