ponisha-mcp

ponisha_api_request

Destructive

Send raw authenticated HTTP requests to any Ponisha API, search, or chat endpoint when no dedicated tool fits; state-changing calls affect the real account.

Instructions

Raw authenticated request (any method) against any Ponisha endpoint. Use only when no dedicated tool fits; state-changing calls act on the real account.

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": {
      "service": "<service>",
      "method": "<method>",
      "path": "<path>"
    },
    "name": "ponisha_api_request"
  }
}

Input Schema

Name	Required	Description
`body`	No
`path`	Yes	Path after the base URL, e.g. /users/me/wallet
`query`	No
`method`	Yes
`service`	Yes	api=api.ponisha.ir/api/v1, search=search.ponisha.ir/v1, chat=chat.ponisha.ir/v1

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.0Nov 6, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, so the risk profile is largely structured data. The description does add real context beyond that: requests are authenticated automatically and mutations hit the live account. It omits error shape, rate limits, and whether responses are passed through raw or unwrapped.

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?

Two short sentences, front-loaded with the capability and immediately followed by the routing constraint. No filler or redundancy.

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

Completeness3/5

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

For a high-blast-radius passthrough with a freeform body and no output schema, the description covers the when and the danger but not the mechanics: no response format, no error semantics, no guidance on constructing bodies for the api/search/chat services. Adequate as a warning label, incomplete as an operating manual.

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

Parameters2/5

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

Coverage is 40% and the untyped 'body' property has no schema at all, yet the description says nothing about body encoding (JSON?), query-string serialization, or path formatting beyond 'any endpoint'. 'Any method' loosely maps to the method enum, but the schema already carries the enum and the service documentation, so the description adds almost nothing param-wise.

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?

States a specific, unambiguous capability: an authenticated raw HTTP request with any method against any Ponisha endpoint. That is clearly different in kind from the CRUD siblings, though it never says which hosts/base URLs exist (that detail lives only in the schema).

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

Usage Guidelines4/5

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

Gives an explicit exclusion rule — 'Use only when no dedicated tool fits' — which is exactly the routing signal an agent needs against 25+ named siblings. It does not, however, address the obvious alternative ponisha_api_get, so an agent must guess whether a GET should go there or here.

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

Deploy Server