ficiel_ne_plus_proposerGeste du bouton Ne plus proposer : le contact sort des relances, comme le refus d’une carte du lot dans Ficiel (tag « Ignorer », levé s’il répond ou si le tag est retiré). Les relances en attente pour cette conversation sont refusées.
| Name | Required | Description | Default |
|---|---|---|---|
| card_id | No | ||
| conversation_id | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a non-read-only, idempotent, non-destructive mutation, and the description goes further: it names the tag applied, states that pending relances for the conversation are refused, and explains the reversal condition (reply or tag removal). That is real behavioral context beyond the annotations. The one gap is it does not say whether the tag application is transactional with the follow-up cancellation.
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?
A single dense sentence with the core effect front-loaded and the reversal condition in a parenthetical. It is appropriately sized, though the nested parenthetical about the 'Ignorer' tag slightly obscures the main consequence on first read.
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?
No output schema and a simple two-parameter mutation, and the description covers behavior and side effects well. However, with 0% schema coverage on both parameters and no clarification of card_id's role, the definition leaves an agent unable to call it confidently with the optional parameter.
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% — neither conversation_id (required) nor card_id is documented anywhere. The description mentions 'conversation' and the card metaphor but never explains what each parameter does, whether card_id is optional or what happens if omitted. With no schema help, the description should have carried this and does not.
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 concretely describes the effect: the contact exits follow-ups and an 'Ignorer' tag is applied, mirroring card refusal in Ficiel. An agent understands the resource and the gesture. It stops short of a 5 because the parallel drawn with 'refus d'une carte' blurs the boundary with reject_card rather than sharpening it.
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?
It indicates the trigger (the widget button 'Ne plus proposer') and the consequence, plus a note that the tag is lifted if the contact replies or the tag is removed, which is useful context. But it never states when to pick this tool over the many sibling mutators (reject_card, defer_card, pause_conversation, blacklist_lead), so selection still requires inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.