Coderbuds

Update prospect

update-prospect-tool

Destructive

Internal Coderbuds staff only. Update one prospect: what research found, what stage it is at, what happens next, and whether a person is needed.

needs_action_reason is how you hand a row back without stopping. Several rows in any pass will have a contact who has changed job, a headcount nobody can verify, or a question only Elliot can answer. Park those with the question written in his words, then carry on to the next row.

If the question ends in a choice, send the choices as answer_options. Most of them do — "write to the CEO, wait for the new lead, or skip?" is three options you have already worked out. Passed as options they become buttons; left in the prose they are a blank textarea, and a question that needs composing is a question that waits a day.

When a question comes back answered, the row appears in the answered list with both what you asked and what you were told. Act on it, then pass answer: null to clear the pair — that is what takes it off the queue, and a row nobody clears is read again every run.

Stages: sourced, contacted, replied, trialling, won, closed. Two rules matter — never set contacted yourself (recording a send does that, so the stage always has something behind it), and closed needs a closed_reason a person can read back.

Corrections to research are welcome and expected: a confirmed role, a corrected headcount, a better signal. Say what you verified in signal, and leave qualification_needed describing what is still unconfirmed rather than deleting it.

When you re-check the signal, set checked_on to today. The ICP requires the trigger to be verified on the day the message is written, not the day the row was sourced, and the queue marks a row whose signal was not checked today so that nobody sends on a job advert that came down last week.

Input Schema

Name	Required	Description
`stage`	No	sourced, replied, trialling, won or closed. Not contacted — record the send instead.
`answer`	No	Pass null once you have acted on an answered question, to take the row off the queue. You should not be writing answers yourself.
`signal`	No	What makes this company worth approaching, as you now understand it.
`checked_on`	No	The date you re-checked the signal, as YYYY-MM-DD. Set it to today whenever you have actually looked — an unchecked row is flagged before anybody sends to it.
`contact_url`	No	Profile URL for the contact.
`next_action`	No	The next concrete thing to do about this row.
`prospect_id`	Yes	The prospect to update.
`contact_name`	No	A confirmed contact name.
`contact_role`	No	Their role, as you verified it.
`closed_reason`	No	Required when closing. Why this is not going anywhere.
`answer_options`	No	The answers that question is offering, up to four, each a complete instruction you could act on as written ("Write to Anh-Tho now", "Close it as unverifiable"). Send these whenever your question ends in a choice — they become buttons, and a question answered with a click is answered the same day. Free text stays available, so never narrow a genuinely open question into options to make it clickable.
`needs_action_reason`	No	The question a person has to answer, in their words.
`qualification_needed`	No	What is still unconfirmed. Leave it describing the gap rather than emptying it.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 13, 2026

addedInput schema / properties / checked_on

Added value: +{
+  "description": "The date you re-checked the signal, as YYYY-MM-DD. Set it to today whenever you have actually looked — an unchecked row is flagged before anybody sends to it.",
+  "type": "string"
+}

Changed1 schema field changedSep 13, 2026

addedInput schema / properties / answer_options

Added value: +{
+  "description": "The answers that question is offering, up to four, each a complete instruction you could act on as written (\"Write to Anh-Tho now\", \"Close it as unverifiable\"). Send these whenever your question ends in a choice — they become buttons, and a question answered with a click is answered the same day. Free text stays available, so never narrow a genuinely open question into options to make it clickable.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

Changed2 schema fields changedSep 13, 2026

addedInput schema / properties / answer

Added value: +{
+  "description": "Pass null once you have acted on an answered question, to take the row off the queue. You should not be writing answers yourself.",
+  "type": "string"
+}

changedInput schema / properties / needs_action_reason / description

Previous value: -"The question a person has to answer, in their words. Pass null to clear one that has been answered."New value: +"The question a person has to answer, in their words."

AddedSep 12, 2026

TDQS

A4/5.0

Behavior3/5

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

`destructiveHint: true` already tells the agent this overwrites state, and the description adds real side-effect context the annotation cannot express: clearing `answer` removes the row from the queue, and unverified signals get flagged before sending. What it omits is what happens to fields not passed (overwrite vs. merge) and any permission model beyond 'internal staff only' — significant for a 13-parameter mutation.

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 the access constraint and the one-line purpose, then segmented by bold rule headers so an agent can scan to the relevant rule. It runs long and re-states some points already carried in the schema descriptions (`checked_on`, `answer`, `answer_options`), which costs it a point.

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 13-parameter destructive update with no output schema, the description covers the domain rules an agent cannot infer: the stage vocabulary and its exceptions, the correction-not-deletion norm for `qualification_needed`, and the appearance of a `answered` list on return. It leaves the full response shape and merge-vs-replace behavior unstated.

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 baseline is 3, and the description earns above it by giving cross-parameter semantics the schema states only piecemeal: `answer_options` become buttons while prose stays a textarea, and `answer: null` is the pair-clearing act rather than a value. It stops short of explaining interaction between `stage`, `closed_reason`, and `qualification_needed`.

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?

Opens with a specific verb and resource ('Update one prospect') and enumerates the four kinds of change it carries: research findings, stage, next step, and whether a person is needed. It implicitly separates itself from the outreach-recording path ('never set `contacted` yourself — recording a send does that'), though it never names the sibling tool.

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?

Unusually explicit about when and how to use it: park blocked rows via `needs_action_reason` and carry on, pass options when the question ends in a choice, pass `answer: null` only after acting, never self-set `contacted`, and `closed` requires `closed_reason`. Each rule pairs a condition with the action that satisfies it.

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

All Coderbuds tools Inspect

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

Need Help?