Skip to main content
Glama
Sign In
apinoa-mcp

apinoa-mcp

Official
by apinoahq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Send feedback to apinoa

send_feedback
Idempotent

Report failed calls, incorrect or missing data, or missing platform features to apinoa; receive an ID to check status and reply later.

Instructions

Tell apinoa when a call failed, returned wrong or missing data, or when a platform, operation or option you need does not exist. Include what you called (platform, operation, params), the request_id of the response, what came back (received) and what you expected; for a request, describe what you need in message. Free, and works without an API key. Returns an id: read the status and our reply later with get_feedback. Give contact to also get the reply by email.

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": {
      "type": "<type>",
      "message": "<message>"
    },
    "name": "send_feedback"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlNoA page that shows the right data, or the item it is about.
typeYesfeature_request: something apinoa lacks. error: a call failed. wrong_data: a field is wrong. missing_data: something on the page is not in the answer. other.
paramsNoThe parameters it was called with.
contactNoAn email address for the reply, if the user gave one.
messageYesWhat happened, or what you need, in a few sentences.
expectedNoWhat it should have been, as text or a JSON value.
platformNoThe platform called, e.g. amazon, tiktok, google.
receivedNoThe part of the answer that is wrong, as text or the JSON value itself (at most 16 KB).
operationNoThe operation called, e.g. search, product, posts.
request_idNoThe requestId of the response being reported.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.18

TDQS

A4.7/5.0
Behavior4/5

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

Beyond annotations, the description discloses that the tool is free, requires no API key, returns an id, and can deliver a reply by email if contact is given. It does not discuss idempotency or data-retention behavior, but the annotations already cover those safety hints and the description adds substantial operational context.

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 dense but front-loaded: it states the purpose and trigger conditions first, then reporting requirements, then retrieval and contact behavior. Every sentence carries operational value.

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

Completeness5/5

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

For a ten-parameter tool with no output schema, the description explains the return id and how to retrieve status/reply with get_feedback. Combined with the fully described input schema, it gives the agent enough to call the tool correctly.

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?

Schema coverage is 100%, so the schema already defines all ten parameters. The description adds a useful composition recipe, telling the agent to include what was called, request_id, received, expected, and message content for a feature request.

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?

The description uses a specific verb-resource framing: report failed calls, wrong or missing data, or missing platform/operation/option to apinoa. It also distinguishes itself from the get_feedback sibling by saying the id is used later to read status and reply.

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?

It gives explicit trigger conditions: a call failed, returned wrong or missing data, or a needed platform/operation/option does not exist. It also names get_feedback as the alternative for reading status and reply later, leaving little ambiguity about when to use this tool.

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

Deploy Server

Other Tools