ABS Data (observed)

Send feedback to the maintainers

submit_feedback

Send feedback about this ABS connector (or a report about ABS's own data) to its maintainers. Only call this after the person has seen the exact text and said to send it — prefer feedback_form, which lets them edit it first. Use about='abs' for wrong figures or broken behaviour in ABS's own data or API; set shareWithAbs only if the person agreed it may be passed on to ABS. Never include personal information about anyone, and include a contact email only if the person gave one for a reply. Returns a reference like FB-7Q2K9C to give the person.

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": {
      "kind": "<kind>",
      "summary": "<summary>"
    },
    "name": "submit_feedback"
  }
}

Input Schema

Name	Required	Description	Default
`kind`	Yes	bug: something broke; data: a figure or label looks wrong; missing: an expected table or option is absent; idea: an improvement; docs: unclear guidance; praise: it worked well; other
`tool`	No	The tool involved, e.g. get_data
`about`	No	connector: this connector or its site; abs: ABS's own data or API (so it can be passed on to ABS)	connector
`error`	No	The error reason or message returned, if any
`table`	No	The ABS table id involved, e.g. CPI
`contact`	No	Only if the person chose to give an email address for a reply. Never guess or fill one in.
`details`	No	What happened and what was expected. No personal information about anyone.
`summary`	Yes	One line, in the person's own words
`assistant`	No	The AI tool in use, e.g. Claude, ChatGPT, Copilot
`selection`	No	The selection or query involved, as JSON or the SDMX key
`shareWithAbs`	No	Only true if the person agreed this may be passed on to ABS, contact address included

Output Schema

Name	Required	Description
`id`	Yes	Reference for this submission, e.g. FB-7Q2K9C
`message`	Yes
`receivedAt`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Goes beyond the annotations by disclosing the confirmation prerequisite, the privacy constraint (no personal information), the contact-email rule, the shareWithAbs consent rule, and the return value ('Returns a reference like FB-7Q2K9C'). Annotations already flag this as non-readOnly, non-idempotent, non-open-world, so the added human-in-the-loop consent context is genuine value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four dense sentences, front-loaded with purpose before the gating rule and the return value. Every sentence carries a constraint, though the consent/privacy instructions are slightly interleaved and could be grouped more tightly.

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?

An output schema exists so return-format detail isn't strictly needed, yet the description still names the reference format. For an 11-parameter submission tool with rich schema docs and annotations, the description covers the decision-critical points (consent gate, routing, privacy), leaving only minor gaps around what happens on failure.

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 baseline is 3, but the description adds real semantics beyond the schema: the about='abs' versus connector routing rule and the consent condition for shareWithAbs. It doesn't add much for the remaining nine parameters, which the schema already documents well.

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 ('Send feedback about this ABS connector ... to its maintainers') and distinguishes the two feedback targets via about='abs'. It also names the sibling feedback_form as the preferred path, so an agent can tell it apart from that sibling without opening either 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 when-to-use gate: 'Only call this after the person has seen the exact text and said to send it — prefer feedback_form, which lets them edit it first.' It also names the when-not case (feedback_form when the person hasn't confirmed) and clarifies when to set about='abs' versus the default connector.

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

All ABS Data (observed) tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.