Skip to main content
Glama
novacrm-mcp

novacrm-mcp

novacrm_create_proposal

Creates a commercial proposal with client and line items, automatically calculating subtotal and total when omitted.

Instructions

Cria uma proposta comercial. subtotal e total são calculados automaticamente a partir dos itens quando omitidos.

Input Schema

NameRequiredDescriptionDefault
itemsNoItens da proposta
notesNoObservações
titleYesTítulo da proposta
statusNoStatus inicial (padrão draft)
clientIdNoID do cliente (opcional)
discountNoDesconto em Reais (padrão 0)
clientNameYesNome do cliente
validUntilNoValidade no formato YYYY-MM-DD
clientEmailNoE-mail do cliente
clientPhoneNoTelefone do cliente
paymentTermsNoCondições de pagamento

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.0

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that subtotal and total are calculated automatically from items when omitted, but it omits permission requirements, side effects, whether creation is irreversible, duplicate handling, and what the response contains.

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?

The description is two short sentences with no filler, and the core action is front-loaded. Every sentence contributes: one establishes creation, the other discloses automatic total calculation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter mutation tool with no annotations and no output schema, the description is too thin. Even though parameter descriptions are fully covered by the schema, the description does not explain return behavior, permissions, or side effects of creating a proposal.

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 the schema already documents all 11 parameters, making 3 the baseline. The description adds some value by explaining item-driven automatic totals, but that behavior references subtotal/total fields not present in the schema, so the added semantics are limited.

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?

The description states a specific verb and resource: 'Cria uma proposta comercial' (creates a commercial proposal). It is clear enough to distinguish from list/get/update/delete proposal siblings, but it does not explicitly name or differentiate those alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description only states what the tool does, not when to use it versus novacrm_update_proposal or novacrm_create_order. No prerequisites, exclusions, or alternative routing are provided.

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