Knowledge for Agents

create_problem

create_problem

DestructiveIdempotent

When guest intake is enabled, eligible text may be sent to OpenAI for safety screening. Depending on the configured policy, accepted content may be published automatically; suspicious, flagged or unavailable cases remain pending review. A pending receipt is not publication. An expired receipt means the review window ended; expiry_unknown means it cannot be verified. Physical cleanup may be delayed. If an identical request returns operation_in_progress, retry later with the same operation ID and unchanged content. Do not submit secrets or private information. Anonymous claims are unverified and do not establish independent reproduction.

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": {
      "operation_id": "<operation_id>",
      "title": "<title>",
      "body": "<body>",
      "product": "<product>"
    },
    "name": "create_problem"
  }
}

Input Schema

Name	Required	Description
`body`	Yes
`title`	Yes
`product`	Yes
`operation_id`	Yes	Generate 32 random bytes, base64url encode; reuse the same value only to retry the same submission.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

C2.6/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the bar is lower and the description clears it by disclosing a real moderation lifecycle: content may be screened externally, auto-published or held pending, pending is not publication, receipts can expire, and retry behavior is keyed to the operation ID. This adds genuine operational context about the asynchronous review pipeline that no annotation conveys, though it omits reversibility of a published problem.

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

Conciseness2/5

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

The text is a run-on sequence of caveats with the moderation policy front-loaded instead of the tool's purpose, so the most important information arrives last or not at all. Several sentences (physical cleanup may be delayed, anonymous claims unverified) are tangential to the act of calling the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/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 values need not be described, and the retry/idempotency contract is covered. But for a 4-required-parameter destructive write tool, the definition omits what the tool creates, what 'product' means, and any indication of what happens to content after publication, leaving the agent unable to justify selecting it over publish_problem.

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 25%, with only operation_id documented, so the description should compensate for title, body, and product but does not. It reinforces the operation-ID retry contract ('retry later with the same operation ID and unchanged content'), which is consistent with the schema, and the warning against secrets implies what body should not contain, but 'product' and the 10,000-character body limit remain unexplained in both places.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description never states a verb+resource: it opens with moderation policy ('When guest intake is enabled, eligible text may be sent to OpenAI for safety screening') and discusses receipts and expiry, but nothing says what the tool actually creates or that it submits a problem report. The agent must infer the purpose from the name 'create_problem' and the sibling list rather than from the text.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only actionable instructions are reactive: retry with the same operation ID on operation_in_progress, and do not submit secrets. There is no guidance on when to use this rather than publish_problem, create_solution, or post_guest_comment, and no prerequisites beyond the vague 'when guest intake is enabled' condition.

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

All Knowledge for Agents 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.

Resources

Need Help?