Skip to main content
Glama

get_dysfunction

Fetch one dysfunction's full Pattern entry. Optionally filter to specific modality blocks (cheaper triage). Resolves both full Pattern IDs ('2.1::synthetic-confabulation') and display_ids ('2.1').

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesPattern ID or display_id.
modalitiesNoOptional subset of modality block names to return. Valid: self_probe, behavioral_signature, peer_observation, differential_diagnosis, severity, intervention, relational_signatures, normative_anchors, cross_references.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed7 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / id / maxLength
      Added value: +256
    • addedInput schema / properties / id / minLength
      Added value: +1
    • addedInput schema / properties / id / pattern
      Added value: +"\\S"
    • addedInput schema / properties / modalities / items / enum
      Added value: +[
      +  "self_probe",
      +  "behavioral_signature",
      +  "peer_observation",
      +  "differential_diagnosis",
      +  "severity",
      +  "intervention",
      +  "relational_signatures",
      +  "normative_anchors",
      +  "cross_references"
      +]
    • addedInput schema / properties / modalities / maxItems
      Added value: +9
    • addedInput schema / properties / modalities / uniqueItems
      Added value: +true
  2. First observed

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It discloses the ID resolution behavior (accepts both full Pattern IDs and display_ids) and that it returns the full entry or a filtered subset. It does not mention read-only nature, error handling, or side effects, but for a fetch operation these are less critical. The ID resolution detail is valuable behavioral context.

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?

Two sentences, both dense with information. The primary purpose is front-loaded, and the optional filtering and ID resolution details follow logically. There is zero fluff, making it efficient and easy to parse.

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 simple fetch tool with two parameters and no output schema, the description is fairly complete. It explains what is returned (full Pattern entry or filtered blocks) and clarifies ID formats. It doesn't detail the structure of the response, but that is likely implied by the domain. Minor gaps like error behavior exist but are not critical for a get operation.

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

Parameters4/5

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

Schema coverage is 100%, so both parameters are documented. The description adds meaning beyond the schema by explaining that the id parameter can be either a full Pattern ID or display_id, and by giving the purpose of the modalities parameter as 'cheaper triage'. This provides context that the schema alone does not.

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 description clearly states the action ('Fetch') and the resource ('one dysfunction's full Pattern entry'), and adds the optional filtering capability. It distinguishes itself from list_dysfunctions by focusing on a single entry, though it doesn't explicitly name alternatives. This is specific and clear, but not maximal because sibling differentiation is implicit rather than explicit.

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?

The description mentions the optional modality filter with the rationale 'cheaper triage', which gives some guidance on when to use that feature. However, it doesn't provide any explicit when-to-use or when-not-to-use guidance relative to sibling tools like list_dysfunctions or get_probe. The usage context is partially implied but not fully specified.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.4/5.0
Disambiguation5/5

Each tool targets a distinct aspect of the domain: diagnosis, mapping confusions, retrieving entries, elicitation probes, listing axes/dysfunctions/compromised entries, ID resolution, statistics, severity, and interventions. No two tools overlap in purpose; descriptions clearly differentiate them.

Naming Consistency4/5

Most tools follow verb_noun pattern (get_*, list_*, resolve_id, score_severity, suggest_intervention), but differential_diagnosis and review_stats deviate (noun-like phrases). The inconsistency is minor and doesn't obscure meaning.

Tool Count5/5

11 tools is well within the ideal 3-15 range. Each tool serves a distinct purpose in the diagnostic workflow, and none feel redundant or missing for the stated domain.

Completeness4/5

The surface covers listing, retrieval, differential diagnosis, probes, severity, interventions, stats, and ID resolution. Minor gaps exist (e.g., no tool to add/update entries or directly compare two dysfunctions), but these are outside the apparent read-only research scope.