Skip to main content
Glama
AI-by-design

Primitiv

by AI-by-design
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

get_conflicts

Read-only

Fetch a paginated, read-only list of design-system conflicts. Filter by type, status, scope, component, or field path to find inconsistencies across sources.

Instructions

Get a bounded, repeatable page of design-system conflicts. Read-only, no side effects. Filter by type, status, scope, exact component name or durable component ID, and a structured fieldPath prefix. Use offset and limit for pagination (default 25, maximum 100). For resolved design values, use get_token or get_component instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNo
limitNo
scopeNo
offsetNo
statusNo
componentNo
fieldPathNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv2.19.0
    • addedInput schema / properties / component
      Added value: +{
+  "maxLength": 4096,
+  "type": "string"
+}
    • addedInput schema / properties / fieldPath
      Added value: +{
+  "items": {
+    "maxLength": 4096,
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 64,
+  "minItems": 1,
+  "type": "array"
+}
    • addedInput schema / properties / limit
      Added value: +{
+  "maximum": 100,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / offset
      Added value: +{
+  "maximum": 1000000,
+  "minimum": 0,
+  "type": "integer"
+}
    • addedInput schema / properties / scope
      Added value: +{
+  "enum": [
+    "all",
+    "cross-source",
+    "within-source"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / status / enum
      Added value: +[
+  "all",
+  "pending",
+  "resolved"
+]
    • addedInput schema / properties / type / enum
      Added value: +[
+  "all",
+  "token",
+  "component"
+]
  2. Changed1 schema field changedv2.1.2
    • removedInput schema / required
      Removed value: -[
-  "type",
-  "status"
-]
  3. Addedv1.8.0
  4. Removedv1.6.0
  5. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, and the description reinforces this with 'Read-only, no side effects' while adding useful behavior: bounded, repeatable pages with pagination defaults. It does not describe sorting or response shape, but for a read-only list tool the disclosed behavior is sufficient.

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

Conciseness5/5

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

Three sentences with no filler: purpose, safety, filters, pagination, and alternatives. The most important facts are front-loaded, and each sentence earns its place.

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 7-parameter read-only paginated endpoint with no output schema, the definition covers the core invocation needs: filters, pagination behavior, and when to choose different tools. It leaves out explicit return details and the relationship to get_violations, but an agent can safely invoke the tool based on this description.

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?

With 0% schema description coverage, the description compensates well: it explains type/status/scope filters, clarifies that component is an exact name or durable ID, describes fieldPath as a structured prefix, and gives pagination defaults. Every parameter in the schema is given some operational meaning.

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?

States a specific verb and resource: 'Get a bounded, repeatable page of design-system conflicts.' It also routes resolved-value lookups to get_token/get_component, but it does not clearly distinguish this from the sibling get_violations, which could overlap in meaning.

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

Usage Guidelines4/5

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

Provides clear context and pagination instructions ('Use offset and limit for pagination, default 25, maximum 100') and explicitly says to use get_token or get_component for resolved design values. It does not, however, say when get_violations or get_inferred_rules would be more appropriate than this tool.

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