sapiens_sintetico

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

The description discloses side effects, costs, and side conditions far beyond the annotations: send is send-only with daily limits and idempotence via transferId, reflexo_generate charges 450 and refunds on failure, sonda charges with estorno and writes nothing, remember writes a binding directive, and companion changes voice mode. It also clarifies that identity always comes from the token and that consent/custom creation acts remain web-only, consistent with readOnlyHint=false and openWorldHint=true.

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?

The description is long, but the scope justifies it: 18 sub-actions, costs, limits, and prerequisites. It is organized into labeled sections (REFLEXO DE SI, CONVITE, LIBERAÇÃO ADMIN, SONDA, PRÓXIMAS JOGADAS, MODO COMPANHIA) and front-loads the core scope. It loses a point for playful ALL-CAPS phrasing and minor duplication, such as repeating the sidebar-button state in companion.

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?

With minimal annotations and no output schema, the description carries a heavy burden and meets it: it specifies return values for key actions (status yields name/foto/Cunho/kind + partnerUserId, bonds yields active+pending, sonda yields hooks), pricing, refunds, idempotency, eligibility gates, and web-only consent boundaries. Only minor response-shape details for admin actions are left unspecified, but the workflow sources are clear.

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?

Even with 94% schema coverage, the description adds workflow-level meaning: toUserId should be sourced from status/bonds, hook comes from the sonda output, amount must be a multiple of 100 with min/max limits, and reuse of the same transferId guarantees no duplicate send. It maps each parameter to the actions that use it, turning a static schema into an actionable decision tree.

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 opens by naming the exact domain — the human↔Sintético bond ('vínculo humano↔Sintético... via MCP') — and bounds it to the logged-in user's own pair. It then enumerates 18 sub-actions with concrete verbs and resources, making it unmistakable what the tool does and clearly distinct from sibling tools like sapiens_persona, sapiens_character, or sapiens_profile.

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?

The description gives strong internal routing: send_context must precede send, invite requires no active bond and has rate-limit/cooldown, and admin actions flow through Helen. It also states explicit exclusions — accepting bond requests and consecrating the Reflexo remain web-only — so the agent knows when not to use this tool. It does not explicitly contrast against sibling tool names, but the domain boundary and sub-action routing are clear.

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