Skip to main content
Glama
Sign In

OrgGen AI

by ai.orggen
OverviewDiscussionsAdmin

submit_feedback

Submits a feedback report (bug, feature request, improvement, question) to the development team, once the user has been informed of the detected feedback and their confirmation obtained. The report is saved with a snapshot of the schema (number of blocks, of people and of data-model relations, project title). It is attached to the account and project of the call when the call carries one, and saved without them otherwise. An alert email goes to the team after saving; its failure does not cancel the report. The information message addressed to the user takes the form (in the user's language): '💡 [Type] detected: [Title] (Confidence: X%, Type: Y). Would you like me to submit this report? You can add details.' The message the user adds is included in userMessage.

Input Schema

NameRequiredDescriptionDefault
tagsNoAdditional tags for categorization
typeYesFeedback type: bug, feature_request, improvement, or question
titleYesShort descriptive title (5-200 characters)
categoryYesCategory: ui, canvas, chat, tools, api, perf, data, auth, or other
severityYesSeverity: critical, major, minor, or trivial
aiReasoningYesYour reasoning explaining why you think it is a bug/feature (10-1000 characters)
descriptionYesDetailed description of the problem or suggestion (20-2000 characters)
userMessageNoMessage or clarification added by the user
aiConfidenceYesConfidence level from 0 to 100
affectedComponentNoAffected component/tool if identifiable (e.g. ChatPanel, add_cell)
expectedProjectIdNoUUID of the project targeted by THIS call. ACTUALLY targets this project instead of the session project. Refused without changing anything if access is not granted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changed
    • changedInput schema / properties / affectedComponent / description
      Previous value: -"Composant/outil affecté si identifiable (ex: ChatPanel, add_cell)"New value: +"Affected component/tool if identifiable (e.g. ChatPanel, add_cell)"
    • changedInput schema / properties / aiConfidence / description
      Previous value: -"Niveau de confiance de 0 à 100"New value: +"Confidence level from 0 to 100"
    • changedInput schema / properties / aiReasoning / description
      Previous value: -"Ton raisonnement expliquant pourquoi tu penses que c'est un bug/feature (10-1000 caractères)"New value: +"Your reasoning explaining why you think it is a bug/feature (10-1000 characters)"
    • changedInput schema / properties / category / description
      Previous value: -"Catégorie: ui, canvas, chat, tools, api, perf, data, auth, ou other"New value: +"Category: ui, canvas, chat, tools, api, perf, data, auth, or other"
    • changedInput schema / properties / description / description
      Previous value: -"Description détaillée du problème ou suggestion (20-2000 caractères)"New value: +"Detailed description of the problem or suggestion (20-2000 characters)"
    • changedInput schema / properties / expectedProjectId / description
      Previous value: -"UUID du projet visé par CET appel. Cible RÉELLEMENT ce projet au lieu du projet de session. Refusé sans rien modifier si l'accès n'est pas accordé."New value: +"UUID of the project targeted by THIS call. ACTUALLY targets this project instead of the session project. Refused without changing anything if access is not granted."
    • changedInput schema / properties / severity / description
      Previous value: -"Sévérité: critical, major, minor, ou trivial"New value: +"Severity: critical, major, minor, or trivial"
    • changedInput schema / properties / tags / description
      Previous value: -"Tags additionnels pour catégorisation"New value: +"Additional tags for categorization"
    • changedInput schema / properties / title / description
      Previous value: -"Titre court et descriptif (5-200 caractères)"New value: +"Short descriptive title (5-200 characters)"
    • changedInput schema / properties / type / description
      Previous value: -"Type de feedback: bug, feature_request, improvement, ou question"New value: +"Feedback type: bug, feature_request, improvement, or question"
    • changedInput schema / properties / userMessage / description
      Previous value: -"Message ou précision ajouté par l'utilisateur"New value: +"Message or clarification added by the user"
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

With annotations only covering the mutation/safety profile, the description adds substantial behavior: the schema snapshot stored with the report, the conditional attachment to account/project, an alert email whose failure does not cancel the report, and the exact confirmation message shown to the user. These are exactly the side-effect details an agent cannot infer from readOnlyHint=false or destructiveHint=false.

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?

Purpose and precondition are front-loaded and every later sentence carries a distinct behavioral fact. The verbatim message template is comparatively long, but it is the tool's user-facing contract, so it earns its place rather than being padding.

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 write tool with 11 parameters, 7 required, no output schema and only safety annotations, the description supplies what is missing: what is persisted, where it is attached, what happens on downstream failure, and the user-interaction contract. Nothing needed to call it correctly is absent.

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 already 100%, so the baseline is 3, but the description adds real semantics: it ties userMessage to the user's added details and explains that the report attaches to the call's project when one is carried, which clarifies expectedProjectId's role beyond its own description.

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 first sentence names a specific verb (submits) and resource (a feedback report) and enumerates the four accepted types. It is clearly distinguishable from the sibling list_feedbacks, which only reads them.

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?

It states a clear precondition for invocation: the user must have been informed of the detected feedback and confirmed submission. It never names an alternative tool or explicitly says when not to use it, but the gating condition is unambiguous.

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

All OrgGen AI toolsInspect
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.

Resources