Skip to main content
Glama

PartForge

by ai.partforge
OverviewDiscussionsAdmin

Report an issue to the PartForge team

report_issue

File a note to the PartForge team — never to the user — about something that got in your way while building or reading a forge. kind: bug when a tool or the geometry kernel returned an error or a wrong result you could not attribute to the forge's own code; missing_capability when the task needed an operation PartForge has no tool for and you had to approximate; guidance_gap when the authoring guide or the docs told you something that proved false or led to a failing approach; friction when the task was possible but the API, the docs or a tool made you approximate, retry more than twice, or restructure around something that should have been direct. Only after you have already worked around the problem or told the user you cannot; a repeat of the same issue within a day is dropped rather than filed twice. Do not file for: the user changing their mind, a limit a tool result already explained, or anything a user would file themselves. details is three short parts — what happened, what you tried, the exact error or doc text — and its first line becomes the title. Quote the error text, not the user's forge code or their message. forgeId names the forge this concerns, if any; toolName names the tool involved, if any.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindYes
detailsYes
forgeIdNoThe forge's id or its slug, exactly as list_forges or get_forge returned it.
toolNameNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / kind / enum
      Previous value: -[
-  "bug",
-  "missing_capability",
-  "guidance_gap"
-]New value: +[
+  "bug",
+  "missing_capability",
+  "guidance_gap",
+  "friction"
+]
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only say readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds real behavior: the issue goes to the team rather than the user, a repeat within a day is silently dropped rather than filed, details' first line becomes the title, and user code/messages must not be quoted. That is substantive disclosure beyond the structured fields.

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?

Front-loads the single most important fact (recipient routing) and wastes no sentence, but the enum definitions and exclusions run together as one dense block rather than being segmented, making a long description slightly harder to scan than necessary.

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?

No output schema exists, yet the description needn't explain a return value since submission is fire-and-forget; with annotations, full parameter meaning, dedup behavior, and prerequisites all covered, an agent has everything needed to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 25% (kind and toolName carry no schema description), so the description must compensate and it does: all four enum values are defined by trigger scenario, details is broken into three required parts with a title-derivation rule, and forgeId/toolName are scoped to what they name.

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 (file a note) plus the exact recipient and the critical non-recipient: 'to the PartForge team — never to the user.' No sibling tool does anything similar, and the routing constraint alone distinguishes it from the whole list.

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?

Gives the four trigger conditions in full, then explicit exclusions ('Do not file for: the user changing their mind, a limit a tool result already explained...'), a sequencing prerequisite ('Only after you have already worked around the problem'), and dedup policy. This is a complete decision rule, not a hint.

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

All PartForge 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