Skip to main content
Glama

express_supplier_interest

Show interest in a DIRECT_SHIP (or any Active) Supply Opportunity for this farm. Writes a Pending farmInterest and opens a support ticket (same as SupplierPage). Requires farm AI key with supplier write role. Set confirm:true to commit.

Input Schema

NameRequiredDescriptionDefault
noteNoOptional note for the support ticket
farmIdYesThe unique farm ID
confirmNoSet true to persist; otherwise dry-run preview
campaignIdYesActive buyingCampaign id
idempotencyKeyNoOptional client key to prevent duplicate interest

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=false. The description adds genuinely new behavioral context beyond them: the write creates a Pending farmInterest AND opens a support ticket, requires a supplier write-role key, and is a dry-run unless confirm:true. No contradictions with the annotations.

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?

Three compact sentences, front-loaded with the purpose, followed by side effects, prerequisites, and the commit flag. Nothing is redundant and no sentence restates the structured fields verbatim.

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 mutating tool with no output schema and rich annotations, the description covers the eligibility scope, authorization requirement, side effects, and dry-run behavior. It omits what happens on failure or what the tool returns, but nothing critical for invoking it correctly is missing.

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%, so all five parameters are already documented; baseline is 3. The description reinforces confirm's dry-run-vs-commit semantics but adds no syntax, format, or validation detail beyond what the schema already provides.

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?

States a specific verb+resource ('Show interest in a ... Supply Opportunity for this farm') and names the concrete side effects (Pending farmInterest, support ticket). It is clearly not any of the sibling list_/get_/log_ tools, but it never names list_supplier_opportunities as the discovery counterpart, so sibling differentiation is implied rather than explicit.

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?

Gives the eligibility condition (DIRECT_SHIP or any Active opportunity), the prerequisite (farm AI key with supplier write role), and the commit gate (confirm:true). It stops short of stating when to prefer this over related tools such as create_supplier_shipment or list_supplier_opportunities.

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