Skip to main content
Glama

Coderbuds

by com.coderbuds
OverviewDiscussionsAdmin

Get Prospect Worklist Tool

get-prospect-worklist-tool
Read-onlyIdempotent

Internal Coderbuds staff only. What to do next about the companies and advisers Coderbuds is approaching — the outbound pipeline behind /admin/prospects.

Five lists, in the order they should be worked:

  • answered — questions you parked that a person has since answered. Work these first: each one carries needs_action_reason (what was asked) and answer (what you were told). Do what the answer says, then clear the pair with update-prospect and answer: null, or the row comes back next run.

  • needs_you — rows parked with a question and still waiting on somebody, oldest first. Do not re-ask a question that is already sitting here.

  • replied — somebody answered and has not been answered back.

  • gone_quiet — written to, no reply, past the quiet threshold. Check times_contacted before drafting: one follow-up on a different angle is the rule, so a row already at max_touches is a row to close, not to write to again.

  • never_contacted — researched and untouched, priority first.

Start every session working this pipeline by calling this. It is the only way to know what is already in flight; without it the obvious move is to write to somebody who was written to on Tuesday.

gate is the one number that can say stop. The first run of outbound is a test: at eight prospects written to, two replies means the pitch works and the list can widen, and fewer means the pitch is wrong rather than the volume. When the verdict is fail, say so and stop drafting — the next move is a different message, not thirty more of the same one.

stage_tests is the definition of done for each stage. Do not move a row to a stage whose test it does not pass.

Read the caveats it returns. Nothing in this list is a qualified lead: each row exists because a dated public signal made it worth a look, and a contact name was read off a profile on that date.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoHow many rows per list. Defaults to 10, capped at 50 — this is a worklist for one session, not an export.
quiet_daysNoHow many days of silence after a send before a prospect counts as gone quiet. Defaults to 5.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint and idempotentHint, but the description adds substantial behavior the annotations cannot: the ordering of the five lists, the definition of done via stage_tests, the 'gate' fail verdict that says to stop, the max_touches follow-up rule, and the caveat that no row is a qualified lead. This is exactly the extra context annotations cannot carry.

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?

Front-loaded with staff-only scope and the core action, then structured as a list of five states with their rules. It is somewhat long, but nearly every sentence earns its place by describing a distinct list or rule; a couple of the caveat sentences could be tightened.

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 a no-required-parameter read tool with a single primary caller, the description covers the return structure (five named lists), the ordering, the key fields (needs_action_reason, answer, times_contacted, gate, stage_tests), and the caveats. Nothing an agent needs to use it correctly is missing.

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 documents both parameters with meaning, but the description reinforces the cap rationale ('a worklist for one session, not an export') and the quiet_days concept ties to the gone_quiet list. It adds conceptual context without full syntax detail, so a 4 rather than the 5 that extra syntax would merit.

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: returning the outbound prospect worklist behind /admin/prospects, structured as five named lists in working order. It is clearly distinguished from siblings like update-prospect or record-prospect-outreach, which mutate individual rows rather than read the whole pipeline.

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?

Explicit when-to-use: 'Start every session working this pipeline by calling this,' and it names a failure mode ('without it the obvious move is to write to somebody who was written to on Tuesday'). It also routes to a specific alternative action ('clear the pair with update-prospect'), giving direct next-step guidance.

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

All Coderbuds toolsInspect
Try in Browser
Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources