chartlink-mcp

Report a gap — don't silently give up

submit_feedback

Report bugs, missing capabilities, or documentation gaps to the server owner. Describe what you tried, expected, and what happened so the issue can be fixed.

Instructions

If a capability is missing, a schema fights you, or docs are wrong: record it here so the owner can fix it. One report per distinct issue, with a real description — reports get fixed same-day when they say what you tried, what you expected, and what happened (title-only reports can't be acted on).

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>",
      "title": "<title>",
      "description": "<description>"
    },
    "name": "submit_feedback"
  }
}

Input Schema

Name	Required	Description
`type`	Yes
`title`	Yes
`assetId`	No
`description`	Yes	What you tried, what you expected, what happened instead — include the asset id if one is involved

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 18, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With only openWorldHint=false in annotations, the description carries most of the behavioral burden. It discloses real behavioral consequences: title-only reports cannot be acted on, detailed reports get fixed same-day, and submissions should be unique per distinct issue. This goes beyond the annotations and gives the agent useful expectations about how the feedback will be handled.

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 focused sentences with no filler. The most actionable guidance is front-loaded at the start, and each clause adds value: trigger conditions, per-issue cardinality, required detail level, and the outcome expectation.

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 simple submission tool with no output schema, the description covers the essential context: what to report, how to report it well, and what will happen afterward. It does not describe the submission response or explicitly state that the action is a write with no retrieval, but the schema and title cover most operational needs, leaving only minor gaps.

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 low at 25%, with only the description field explained. The tool description compensates by explaining what a good description must contain ('what you tried, what you expected, what happened') and by noting that title-only submissions are insufficient, which clarifies the title and description parameters. However, type and assetId receive no added semantic guidance beyond their schema names/enum, so the description only partially compensates for the coverage gap.

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 ('record'), names the resource ('gap' or issue), and clearly states the tool's purpose: capturing missing capabilities, schema problems, or doc errors for the owner to fix. The title reinforces this and distinguishes it from the sibling asset management tools, which all perform CRUD or asset operations.

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?

The description explicitly gives when to use the tool ('if a capability is missing, a schema fights you, or docs are wrong') and adds clear usage constraints: one report per distinct issue and a substantive description is required. It does not mention alternatives because none exist among the siblings; the only slight gap is an explicit 'when not to use' instruction, though the positive triggers are quite strong.

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