Prosp

List circular opportunities

list_circular_opportunities

Read-onlyIdempotent

List circular-economy opportunities inferred from the customer's OWN stored business profile: for each, the flow, asset, spare capacity or capability it rests on and the kind of company that completes it. Does not run a discovery and does not cost credits. The list is dated by computed_at — when it was DERIVED, not when you asked — and is never padded, so an empty list means nothing is well-grounded.

READ speech_act BEFORE YOU USE A LABEL. Each of resource and counterpart carries one, graded independently. ASSERT means the customer told us this and you may state it back. ASK means WE INFERRED IT, so refer to it only as a question ('do you have spare kiln capacity?'), never as a fact ('your spare kiln capacity').

The two elements are NOT the same kind of claim. resource is about the customer's OWN business; counterpart is a hypothesis about which kind of company would want it, and it is ASK on nearly every entry — that is normal and does not make the entry unusable.

outreach_draft_eligible answers ONE question: may this entry ground a draft at all. It turns on the resource, because that is what a message would be ABOUT. false means do not compose outreach from it in any form, not even as a question. true means you may write about the resource — it does NOT license asserting the counterpart; that element's own speech_act still governs it, so write the market as an open question, not as a need you have established.

Do not re-order the list: the order is server-authoritative and shared with every other surface these opportunities appear on. Pass an entry's handle to run_circular_opportunity to search for its counterparts.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_circular_opportunities"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations it discloses several non-obvious traits: no credit cost, no discovery executed, `computed_at` reflects derivation time rather than request time, and the list is never padded so an empty result is meaningful. It also declares the ordering server-authoritative and shared across surfaces, which is exactly the kind of constraint an agent would otherwise violate.

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?

Purpose and the no-cost/no-discovery caveat are front-loaded in the first sentence, and the paragraph on `speech_act` is signaled with a capital-letter directive that is easy to scan. It is long for a zero-argument list tool, and the resource-vs-counterpart distinction is restated across two paragraphs, but nearly every sentence carries interpretive weight that the output schema alone would not convey.

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 tool whose real complexity is in interpreting graded output fields, the description covers the traps thoroughly: speech_act per element, the asymmetry between resource and counterpart, what outreach_draft_eligible does and does not license, and the meaning of an empty list. An agent can act correctly on the response without further guidance.

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 the baseline is 4 and there is nothing for the description to clarify on the input side. Its detailed field semantics apply to the response rather than the schema, which is contextually useful but does not raise this dimension.

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?

The opening sentence names a specific verb and resource ('List circular-economy opportunities') and pins the data source ('inferred from the customer's OWN stored business profile'), which cleanly separates it from run_circular_opportunity and find_prospects. The parenthetical describing what each entry carries (flow, asset, spare capacity, capability, completing company) removes any ambiguity about what a returned item is.

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 explicitly rules out two alternatives ('Does not run a discovery and does not cost credits') and routes the agent forward by saying to pass an entry's `handle` to run_circular_opportunity for counterpart search. It also forbids re-ordering. What's missing is a positive statement of when this tool is the right call (e.g. 'before drafting outreach, list what's already available'), so the agent must infer the entry condition.

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

All Prosp tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?