Skip to main content
Glama

contribute_community_print

Destructive

Contribute an anonymous print outcome to a community registry for aggregation; only geometric signatures, settings, and outcome are stored—never files, user IDs, or paths.

Instructions

Contribute a print outcome to the community registry.

        Adds an anonymous print record for community aggregation.
        Only geometric signatures and settings are stored — never
        file contents, user IDs, or file paths.

        Args:
            geometric_signature: Geometric signature from fingerprinting.
            printer_model: Printer model name.
            material: Material used.
            settings: The slicer settings the print used, as a flat
                name→value dict (e.g. ``{"layer_height_mm": 0.2,
                "infill_percent": 20, "nozzle_temp_c": 215}``).  Stored
                as given and hashed for matching; no key is required.
            outcome: ``"success"``, ``"failed"``, or ``"partial"``.
            quality_grade: One of ``"A"``, ``"B"``, ``"C"``, ``"D"``,
                ``"F"`` (default ``"B"``).
            failure_mode: Optional failure description.
            print_time_seconds: Print duration in seconds.
            job_id: The print's job id when known — it anchors the
                federation dedupe key, so a print that was also
                watched (or recorded via ``record_print_outcome``)
                ships to the community pool once, not twice.
            geometric_signature_v2: ``fingerprint_model``'s
                ``geometric_signature_v2``.  Pass it: it is what keeps
                this contribution from being averaged into a different
                design that shares the older signature.
        

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": {
      "geometric_signature": "<geometric_signature>",
      "printer_model": "<printer_model>",
      "material": "<material>",
      "settings": "<settings>",
      "outcome": "<outcome>"
    },
    "name": "contribute_community_print"
  }
}

Input Schema

NameRequiredDescriptionDefault
job_idNoThe print's job id when known — it anchors the federation dedupe key, so a print that was also watched (or recorded via ``record_print_outcome``) ships to the community pool once, not twice.
outcomeYes``"success"``, ``"failed"``, or ``"partial"``.
materialYesMaterial used.
settingsYesThe slicer settings the print used, as a flat name→value dict (e.g. ``{"layer_height_mm": 0.2, "infill_percent": 20, "nozzle_temp_c": 215}``). Stored as given and hashed for matching; no key is required.
failure_modeNoOptional failure description.
printer_modelYesPrinter model name.
quality_gradeNoOne of ``"A"``, ``"B"``, ``"C"``, ``"D"``, ``"F"`` (default ``"B"``). Default: "B".
print_time_secondsNoPrint duration in seconds. Default: 0.
geometric_signatureYesGeometric signature from fingerprinting.
geometric_signature_v2No``fingerprint_model``'s ``geometric_signature_v2``. Pass it: it is what keeps this contribution from being averaged into a different design that shares the older signature. Default: "".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changedv1.5.1
    • addedInput schema / properties / failure_mode / description
      Added value: +"Optional failure description."
    • addedInput schema / properties / geometric_signature / description
      Added value: +"Geometric signature from fingerprinting."
    • changedInput schema / properties / geometric_signature_v2 / description
      Previous value: -"Default: \"\"."New value: +"``fingerprint_model``'s ``geometric_signature_v2``.  Pass it: it is what keeps this contribution from being averaged into a different design that shares the older signature. Default: \"\"."
    • addedInput schema / properties / job_id / description
      Added value: +"The print's job id when known — it anchors the federation dedupe key, so a print that was also watched (or recorded via ``record_print_outcome``) ships to the community pool once, not twice."
    • addedInput schema / properties / material / description
      Added value: +"Material used."
    • addedInput schema / properties / outcome / description
      Added value: +"``\"success\"``, ``\"failed\"``, or ``\"partial\"``."
    • changedInput schema / properties / print_time_seconds / description
      Previous value: -"Default: 0."New value: +"Print duration in seconds. Default: 0."
    • addedInput schema / properties / printer_model / description
      Added value: +"Printer model name."
    • changedInput schema / properties / quality_grade / description
      Previous value: -"Default: \"B\"."New value: +"One of ``\"A\"``, ``\"B\"``, ``\"C\"``, ``\"D\"``, ``\"F\"`` (default ``\"B\"``). Default: \"B\"."
    • addedInput schema / properties / settings / description
      Added value: +"The slicer settings the print used, as a flat name→value dict (e.g. ``{\"layer_height_mm\": 0.2, \"infill_percent\": 20, \"nozzle_temp_c\": 215}``).  Stored as given and hashed for matching; no key is required."
  2. Changed8 schema fields changedv1.5.0
    • removedInput schema / properties / failure_mode / default
      Removed value: -null
    • removedInput schema / properties / geometric_signature_v2 / default
      Removed value: -""
    • addedInput schema / properties / geometric_signature_v2 / description
      Added value: +"Default: \"\"."
    • removedInput schema / properties / job_id / default
      Removed value: -null
    • removedInput schema / properties / print_time_seconds / default
      Removed value: -0
    • addedInput schema / properties / print_time_seconds / description
      Added value: +"Default: 0."
    • removedInput schema / properties / quality_grade / default
      Removed value: -"B"
    • addedInput schema / properties / quality_grade / description
      Added value: +"Default: \"B\"."
  3. Changed1 schema field changedv1.3.1
    • addedInput schema / properties / geometric_signature_v2
      Added value: +{
      +  "default": "",
      +  "title": "Geometric Signature V2",
      +  "type": "string"
      +}
  4. Changed1 schema field changedv1.3.0
    • addedInput schema / properties / job_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Job Id"
      +}
  5. First observedv0.1.0

TDQS

A3.6/5.0
Behavior4/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=true, openWorldHint=false), the description discloses what is actually stored — geometric signatures and slicer settings only, never file contents, user IDs, or file paths — which is exactly the privacy context an agent needs before writing to a shared pool. It also explains the federation dedupe behavior keyed on job_id and why geometric_signature_v2 prevents cross-design averaging, though it says nothing about failure modes or whether a contribution can be retracted.

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

Conciseness3/5

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

The privacy and dedupe context is correctly front-loaded in the first two paragraphs, but the long Args section duplicates the input schema verbatim and inflates the definition without adding new information. Roughly half the text could be dropped with no loss for an agent that also sees the schema.

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

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a ten-parameter mutation tool with no output schema, the description covers the essential unknowns: anonymity scope, what is persisted, matching/hashing of settings, and dedupe via job_id. It stops short of describing the response or any rate/consent constraints on community submission, which is a minor gap given the annotations already flag the write as destructive.

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 100%, so the schema already documents all ten parameters, and the Args block in the description largely restates those same texts. The only added meaning is the concrete settings example and the matching rationale for geometric_signature_v2, which the schema also carries, so baseline 3 applies.

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

Purpose4/5

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

The first line states a specific verb and resource: contribute a print outcome to the community registry, and the second line clarifies it writes an anonymous aggregation record. It does not explicitly contrast itself with the closest sibling, record_print_outcome, outside of the job_id rationale, so an agent must infer the split.

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

Usage Guidelines3/5

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

Usage is implied by the title and by the note that a print already recorded via record_print_outcome will be deduped through job_id, which hints at the alternative. However, there is no explicit 'use this when / use X instead when' statement and no prerequisites or conditions are given.

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

Deploy Server

Other Tools