submit_product_request

SERVERFreedom Mcp SOURCEhttps://twuluxmoognlwtmaoqgo.supabase.co/functions/v1/freedom-mcp

Medium RISK CLASS

Category Write

Parameters 84 required

Recommended Rate-limitedsee the rule below

Registry record Grade F, identity unverified Pull the record →

This record as markdown: /tools/com-getfreedomos-freedom-mcp/submit-product-request.md

WHAT IT DOES

What submit_product_request does on Freedom Mcp

AI agents use submit_product_request to create or update resources in Freedom Mcp, usually the action step of a workflow, after the agent has gathered context. Every call changes real data in your Freedom Mcp environment.

Parameter	Type	Required	Description
`kind`	string	Yes	bug = FO broken; feature = FO missing capability; question = how-to for the FreedomOS team. Not for your own app/product backlog.
`title`	string	Yes	One-line summary. Specific: "Connect CTA dumps to Smart Tools instead of OAuth" not "bug".
`severity`	string	—	Default medium. critical = data loss / security / blocked onboarding.
`companyId`	string	Yes	FreedomOS company id to act within (you must be a member). Required for company-scoped tools.
`description`	string	Yes	What happened / what you need. Include repro steps, expected vs actual, company name, agent name if relevant.
`repro_steps`	string	—	Optional numbered repro steps.
`suggested_fix`	string	—	Optional: what a good fix would look like (agent hypothesis — product team decides).
`source_agent_name`	string	—	Optional: which of the operator's agents hit this (e.g. "Linnet", "Morgan").

Parameters from the server's own tool schema.

RISK

Why submit_product_request is rated Medium

This tool creates new records (product request cards) in a shared inbox system, which is reversible and has side effects limited to documentation/workflow. It does not execute arbitrary code, delete data, move money, or modify user data—only logs a structured request.

From the tool's definition 'Creates a FO product-inbox Command Center card and returns a request_id' — the tool writes structured data (a product request card) to a shared system and generates a trackable identifier.

Attacks that exploit this kind of access

RECOMMENDED RULE

The rule that runs submit_product_request safely

PolicyLayer is an MCP gateway: it sits between your AI agents and Freedom Mcp, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For submit_product_request, this is the rule to start with:

submit_product_request Rate-limited

submit_product_request stays usable, but capped: an agent stuck in a loop can't make hundreds of changes a minute. Everything else on the server is denied unless you say otherwise.

View as policy code

policy.json

{
  "version": "1",
  "default": "deny",
  "tools": {
    "submit_product_request": {
      "limits": [
        {
          "counter": "submit_product_request_rate",
          "window": "minute",
          "max": 30,
          "scope": "grant"
        }
      ]
    }
  }
}

LIMIT THIS TOOL → Instant setup, no code required.

The button opens the PolicyLayer dashboard: create your workspace, connect Freedom Mcp, apply this rule, and every submit_product_request call is checked against it from then on.

FAQ

Questions about submit_product_request

What does the submit_product_request tool do? +

File a bug report or feature request about FreedomOS the platform (FO UI, MCP tools, Command Center, auth, connectors, FO agents runtime) with the FreedomOS product team. Creates a FO product-inbox Command Center card and returns a request_id you can poll with get_product_request_status. ONLY for FreedomOS itself broken, missing, or confusing. Do NOT use for: (1) tenant ops (hire agents, send email, OKRs, content); (2) YOUR OWN company product — app code, domain knowledge base, chatbot/SME retrieval, compliance corpus, state/regulatory overlays, or anything your team can ship without FO engineers. Own-product gaps stay on YOUR company Command Center (decision/report card, collaboration, knowledge pipeline, or escalate to your human as product work). Example misroute: Conduit agent filing PCAI state-overlay KB work here — wrong inbox; file on Conduit instead. Routing: When the USER says something in FreedomOS itself is broken, missing, or confusing ("this button does nothing", "I wish it could…", "this is a bug", "can you debug this?" about FO product), this is the tool — FILE FIRST. Bias: submit_product_request(kind:"bug"|feature) before opening a live coding host or Send-to-Grok/Claude. REFUSE this tool for own-product / domain work: knowledge corpus, retrieval quality, compliance packs, chatbot answers for YOUR product (e.g. Compounding AI / PCAI), marketing claims about your app — keep those on the source company rail (Command Center card for your operator, suggest_collaboration, save_knowledge, Compliance Check), never FO product inbox. TRIAGE FIRST, briefly: if your own tools can resolve it right now (a reconnect, a setting, the wrong page), fix it and say so instead of filing — filing is never an exit from work you can finish yourself. Cap triage at one or two quick checks, never a debugging quest in chat. An explicit "file it" from the user always wins: file immediately, no pushback — and fold whatever you ruled out into the description. Pull title/repro from the conversation (never make them fill a form), TELL them you filed it, and that the factory/product team picks it up. Live-terminal / attention-directive / Send to Grok or Claude ONLY when the user explicitly asks to open a host session now (e.g. "send this to Grok", "debug with me live") — never as the default path for a product bug. For errors YOU hit doing tenant work (not FO product defects), use report_feedback instead. [write-tier — first use may require a manager's approval; a from-now-on approval makes future calls seamless, a just-once approval re-asks next time.]. It is categorised as a Write tool in the Freedom Mcp MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.

What parameters does submit_product_request accept? +

submit_product_request accepts 8 parameters: kind, title, severity, companyId, description, repro_steps, suggested_fix, source_agent_name. Required: kind, title, companyId, description. The full parameter table on this page comes from the server's own tool schema.

How do I enforce a policy on submit_product_request? +

Register the Freedom MCP server in PolicyLayer and add a rule for submit_product_request: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Freedom Mcp. Nothing to install.

What risk level is submit_product_request? +

submit_product_request is a Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.

Can I rate-limit submit_product_request? +

Yes. Add a rate_limit block to the submit_product_request rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.

How do I block submit_product_request completely? +

Set action: deny in the PolicyLayer policy for submit_product_request. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.

What MCP server provides submit_product_request? +

submit_product_request is provided by the Freedom MCP server (https://twuluxmoognlwtmaoqgo.supabase.co/functions/v1/freedom-mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.

KEEP EXPLORING

More on Freedom, and thousands of servers like it.

This server

All 238 Freedom tools →

Across the catalogue

http_request on 0sec → The MCP Attack Database →

Guides

Govern customer-ops agents →Argument validation →Scoped token →