Skip to main content
Glama

Add Prospect Tool

add-prospect-tool

Internal Coderbuds staff only. Add a company or adviser to the outbound pipeline.

The buyer to look for: a CTO, head of engineering or hands-on engineering manager at a product company with 10–30 engineers on GitHub or Bitbucket. Coderbuds does not support GitLab — a GitLab-only team is not a prospect, however good the fit otherwise looks.

Give the signal that made them worth writing down and the source_url it came from, and put what you could not verify in qualification_needed rather than guessing. A row whose signal is "looked like a fit" is a row nobody can act on later.

Everything starts at Sourced regardless of what you pass. Duplicates are worth checking for first with get-prospect-worklist.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNocompany or partner. An adviser — fractional CTO, consultancy — is a partner.company
nameYesCompany or adviser name.
signalNoWhat makes them worth approaching now.
websiteNoTheir website.
locationNoWhere they are based.
priorityNoA, B or C.
source_urlNoWhere the signal came from, so it can be rechecked.
contact_urlNoProfile URL for that person.
next_actionNoThe first thing to do about them.
contact_nameNoWho to approach.
contact_roleNoTheir role as published, not as inferred.
qualification_neededNoWhat you could not verify.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior4/5

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

No annotations are present, so the description carries the full burden, and it does disclose real behavior: the staff-only restriction and that every row starts at 'Sourced' regardless of passed values. It stops short of saying what happens on a duplicate (rejected, merged, or created anyway) or what is returned, so a small but meaningful gap remains.

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?

The access restriction is front-loaded and the ICP, exclusion, and data-quality guidance are all actionable. It is slightly verbose with stylistic asides ('a row nobody can act on later'), but every paragraph carries information the agent needs.

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 12-parameter mutation with no annotations and no output schema, the description supplies the domain rules (ICP, GitLab exclusion, dedupe prerequisite, default status behavior) that schemas cannot express. It is close to complete; only duplicate-handling outcome and return behavior are left unstated.

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 100% on all 12 parameters, so the schema already defines kind, signal, source_url, qualification_needed and the rest. The description adds emphasis on signal quality and the significance of qualification_needed, but no syntax, format, or enum detail beyond what the schema provides. Baseline 3 is appropriate.

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 ('Add a company or adviser to the outbound pipeline') and the next line disambiguates the sibling space by describing the buyer and the GitLab exclusion. An agent can distinguish this from save-prospect-draft-tool and update-prospect-tool without opening schemas.

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?

Gives an explicit audience restriction ('Internal Coderbuds staff only'), an explicit exclusion (GitLab-only teams are not prospects), and a named alternative with a condition ('Duplicates are worth checking for first with get-prospect-worklist'). That is when-to-use, when-not-to-use, and the alternative all in one.

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