Skip to main content
Glama

AILANG Parse

by io.github.sunholo-data

submit_feedback

Anonymous bug report / feature request / docs gap, queued for human review. Default routing: public-feedback inbox (general AILANG). Pass package="vendor/name" (e.g. "sunholo/auth") to route to that package's pkg:vendor/name inbox where its autonomous agent watches. Categories: bug, feature, docs, limitation. Body limit 10KB, snippet limit 4KB. Optional contact field for follow-up; opaque to the server. Set auto_dispatch=true to authorize the package agent to act on your submission immediately (default false — files for human triage; pkg-feedback agent template lands in a separate sprint).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyYesFull description (≤10 KB)
titleYesShort title for the report
contactNoOptional follow-up address (free-form, opaque to the server)
packageNoOptional vendor/name (e.g. "sunholo/auth") to route to that package's pkg:vendor/name inbox. Empty = general AILANG feedback.
snippetNoOptional code/error snippet (≤4 KB)
categoryYesbug | feature | docs | limitation
auto_dispatchNoAuthorize the receiving package's autonomous agent to act on this submission. Default false (files for human triage). Tagged on the Pub/Sub notification as category=auto:<original> for coordinator filtering.
ailang_versionYesThe reporter's CLI version (free-form, used for triage)

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Added

TDQS

A4.9/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden. It discloses key behaviors: queued (not immediate), anonymous, body/snippet limits, contact field opacity, and the effect of auto_dispatch (immediate action vs human triage, separate sprint). This is comprehensive and beyond what any structured fields would provide.

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?

Despite covering many details (routing, limits, categories, auto_dispatch), the description remains dense and efficient. It front-loads the core purpose and routing, then appends essential constraints. Every sentence adds value, with no fluff.

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?

With 8 parameters, no output schema, and no annotations, the description provides comprehensive context: default routing, package routing, limits, category enum, contact field behavior, and auto_dispatch implications. It fully prepares an agent to invoke the tool correctly, even without schema descriptions.

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 covers 100% of parameters, but the description adds meaningful context beyond schema descriptions: the 'package' param's routing to an agent-watching inbox, and auto_dispatch's 'files for human triage' and 'separate sprint' nuance. While the schema already explains most parameters, the description enriches the behavioral understanding of routing and dispatch.

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 clearly states the tool's purpose: 'Anonymous bug report / feature request / docs gap, queued for human review.' This specifies the verb (submit), the resource (feedback), and the scope (bug/feature/docs), distinguishing it from sibling tools which are mostly API/auth utilities. The purpose is immediately evident and unambiguous.

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?

Provides explicit routing guidance: default to public-feedback inbox, or pass package to route to a package-specific inbox. It explains when to set auto_dispatch=true (to authorize package agent) versus default (human triage), and mentions categories. This gives clear context for when and how to use the tool versus alternatives.

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

All AILANG Parse toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.5/5.0
Disambiguation4/5

Most tools have clear, distinct purposes: parse, convert, estimate, formats, auth, auth-poll, account, upload, and feedback. The main ambiguity is that editDocument with an empty delta array behaves like a parse, overlapping with mcpParse.

Naming Consistency2/5

Seven tools share a useful mcp prefix with PascalCase, but editDocument and getUploadUrl are camelCase and submit_feedback is snake_case. The casing and verb-style inconsistencies make the tool set feel less coherent than its overall design suggests.

Tool Count5/5

Ten tools is a well-scoped size for this domain: authentication, account, upload, formatting, estimation, parsing, editing, conversion, and feedback are each represented. No tool feels redundant or like filler.

Completeness4/5

The surface covers the key parse workflow: get an API key, upload, estimate, parse, edit, convert, and check supported formats. Minor gaps exist, such as no explicit API-key revoke action and some output/workflow steps being delegated to the SDK/CLI.

Resources