ponisha-mcp

ponisha_update_bid

Modify an editable Ponisha bid by updating its amount, delivery days, description, or milestones; pass current values for any unchanged fields.

Instructions

Edit one of your bids (amount in Toman, days, text, milestones). Only works while the bid's is_editable is true (see ponisha_my_bids). All fields are required, so pass the current values for anything you don't change. Ponisha has no way to withdraw a bid.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project_id": "<project_id>",
      "bid_id": "<bid_id>",
      "amount": "<amount>",
      "days": "<days>",
      "description": "<description>"
    },
    "name": "ponisha_update_bid"
  }
}

Input Schema

Name	Required	Description	Default
`days`	Yes
`amount`	Yes
`bid_id`	Yes
`payments`	No
`project_id`	Yes
`description`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.0Nov 6, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations only declare the generic non-read-only, non-destructive, open-world profile; the description adds real behavior beyond that: a server-side editability gate, full-replacement semantics (all fields required, unchanged values must be resent), and the irreversibility caveat that bids cannot be withdrawn. It stops short of saying what a successful edit returns or whether clients are notified of an amount change.

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 short sentences, each earning its place: what it edits, the gate that blocks it, and the destructive caveat. The precondition is front-loaded immediately after the purpose.

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 6-parameter mutation with no output schema and only generic annotations, the description covers the failure mode, the input contract, and the irreversibility that matters most for a bid. Minor residual gaps are return value and whether an edit affects an already-submitted proposal on the client side.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Top-level schema description coverage is 0%, so the description carries the burden, and it supplies the crucial unit interpretation (amount in Toman) and maps "text"/"milestones" to the description/payments fields, plus the replace-all rule that materially changes how every parameter must be supplied. It leaves project_id and bid_id roles, and the shape of the milestone entries, to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Edit one of your bids") and enumerates the editable surface (amount in Toman, days, text, milestones). An agent can distinguish this from sibling ponisha_submit_bid (create) and ponisha_get_bid (read) without opening any schema.

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

Usage Guidelines5/5

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

Explicit precondition ("Only works while the bid's is_editable is true") with a pointer to the sibling tool that exposes that flag (ponisha_my_bids), plus the operational rule to pass unchanged current values. It also warns that no withdrawal path exists, which steers the agent away from misusing this tool as a cancel.

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

Deploy Server