Returns provider-specific task details, examples, output fields, and official connection steps for preparing a referral without executing tasks or creating accounts.
Return provider-specific task, example, output fields and official connection steps. No execution, account creation, secrets, purchase or attribution.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes |
Changes observed during successful MCP inspections.
v0.2.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It does usefully disclose non-mutation boundaries (no execution, no account creation, no secrets, no purchase, no attribution), but it says nothing about how sensitive_data or sources_permitted alter what is returned, nor about rate limits or any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences that front-load what is returned and then enumerate what is forbidden. No redundant restatement of the tool name, though the second sentence reads as a bare keyword list rather than a rationale.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single nested parameter object, no annotations, and no output schema, the description's definition of returned artifacts plus its explicit non-actions covers most of what an agent needs. The main unmet need is the semantics of the two boolean flags.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does not. 'Provider-specific' weakly hints at provider_id, but the two boolean flags (sensitive_data, sources_permitted) are completely unexplained — an agent cannot know whether they gate, redact, or reshape the returned guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the outputs (provider-specific task, example, output fields, official connection steps), which tells the agent the tool produces preparatory guidance rather than performing anything. However, 'task' is ambiguous, and it never explains how this differs from list_referral_providers or recommend_referral_service, which sit in the same referral workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the negative list ('no execution, account creation, secrets, purchase or attribution') signals that this is a pre-execution information step, likely after a provider has been recommended. No explicit when-to-use or when-not-to-use-vs-siblings statement is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.