Skip to main content
Glama

get_community_insight

Read-only

Retrieves aggregated print data for a model geometry, combining local success rates, materials, settings, and failure modes with optional community-wide print insights.

Instructions

Get aggregated print data for a model geometry.

        Two layers, and the tool always returns whatever it can get:

        * ``insight`` — what THIS install has printed of this
          geometry: success rate, printers, materials, settings,
          failure modes.  Always available, no account needed.
        * ``community`` — the same picture across everyone who has
          printed this shape, so you can start from what already
          worked.  Community insights come with Kiln Pro; without them ``community``
          reports that it isn't available and the local layer is
          unaffected.

        Never fails because of the network or the plan: no
        connection, no account, or a plan without community
        insights all still return the local answer.

        Args:
            geometric_signature: Geometric signature to look up
                (``fingerprint_model``'s ``geometric_signature``).
            geometric_signature_v2: The same mesh's
                ``geometric_signature_v2``, when known.  Supplying it
                narrows the answer to THIS design: without it, prints
                of a different design that happens to share the older
                signature can be counted into the result.
        

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>"
    },
    "name": "get_community_insight"
  }
}

Input Schema

NameRequiredDescriptionDefault
geometric_signatureYesGeometric signature to look up (``fingerprint_model``'s ``geometric_signature``).
geometric_signature_v2NoThe same mesh's ``geometric_signature_v2``, when known. Supplying it narrows the answer to THIS design: without it, prints of a different design that happens to share the older signature can be counted into the result. Default: "".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.5.1
    • addedInput schema / properties / geometric_signature / description
      Added value: +"Geometric signature to look up (``fingerprint_model``'s ``geometric_signature``)."
    • changedInput schema / properties / geometric_signature_v2 / description
      Previous value: -"Default: \"\"."New value: +"The same mesh's ``geometric_signature_v2``, when known.  Supplying it narrows the answer to THIS design: without it, prints of a different design that happens to share the older signature can be counted into the result. Default: \"\"."
  2. Changed2 schema fields changedv1.5.0
    • removedInput schema / properties / geometric_signature_v2 / default
      Removed value: -""
    • addedInput schema / properties / geometric_signature_v2 / description
      Added value: +"Default: \"\"."
  3. Changed1 schema field changedv1.3.1
    • addedInput schema / properties / geometric_signature_v2
      Added value: +{
      +  "default": "",
      +  "title": "Geometric Signature V2",
      +  "type": "string"
      +}
  4. First observedv0.1.0

TDQS

A3.9/5.0
Behavior5/5

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

Beyond the readOnly/openWorld annotations, the description discloses the key runtime behaviors: partial results are always returned, the community layer degrades independently with an 'unavailable' marker, and the call never fails due to network or plan state. That degradation contract is exactly the kind of information the annotations cannot carry.

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-loaded and well structured with a lead sentence, a bulleted layer breakdown, and a robustness statement. The trailing Args section duplicates the schema descriptions and is the one clearly removable block.

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?

With no output schema, the description does the necessary work by enumerating what each layer contains (success rate, printers, materials, settings, failure modes) and how the degraded response looks. It stops short of naming actual response fields, but the shape is clear enough to act on.

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 coverage is 100%, so both parameters are already documented. The Args block restates the schema text almost verbatim, including the caveat about the older signature over-matching, so it adds no meaning beyond structured data; 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 gives a specific verb and resource (aggregated print data for a model geometry), and the two-layer breakdown makes the returned content concrete. It does not name or contrast with nearby siblings such as community_stats, get_model_print_history, or contribute_community_print, so an agent must infer the boundary itself.

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 rather than stated: it says the local layer is always available and the community layer requires Kiln Pro, and hints at the workflow by pointing to fingerprint_model's signature. There is no explicit when-to-use/when-not statement and no named alternative for the overlapping siblings.

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