psychopathia-mcp

by NellInc

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct function: differential diagnosis, retrieving pattern details, probing modalities, listing axes, checking compromised self-report, filtering dysfunctions, resolving IDs, reviewing statistics, scoring severity, and suggesting interventions. No two tools have overlapping purposes.
Naming Consistency4/5
Most tools follow a clear verb_noun pattern (get_, list_, resolve_, review_, score_, suggest_). One outlier ('differential_diagnosis') uses noun_noun, but overall the naming is consistent and predictable.
Tool Count5/5
11 tools cover the core operations for a diagnostic reference server: listing, retrieval, differential analysis, severity scoring, and intervention suggestions. The count feels well-scoped without unnecessary redundancy.
Completeness4/5
The tool set provides comprehensive read operations and analytical functions (diagnosis, severity, intervention). Missing CRUD operations for modifying the taxonomy, but given the read-heavy nature of a diagnostic reference, this is a minor gap.
Average 3.4/5 across 11 of 11 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention permissions, side effects, rate limits, or whether it is read-only. The return structure is not described.
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 description is a single sentence, but it is dense and uses technical terms without explanation. Conciseness is acceptable, but clarity suffers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain what is returned. It only hints at the nature of the results (confusing dysfunctions) but lacks details on format, pagination, or ordering. The simple input parameter is somewhat addressed.
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?
The description implicitly relates the 'dysfunction_id' parameter to the dysfunction being queried, stating 'All dysfunctions that confuse with this one'. This adds minimal but necessary meaning beyond the schema, which has 0% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description vaguely states it returns 'all dysfunctions that confuse with this one', but uses cryptic jargon like 'forward confuses_with + incoming_references (reverse graph from manifest)'. It does not clearly specify the action or output format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its siblings (e.g., differential_diagnosis, get_dysfunction). The description offers no context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It does not mention side effects, permissions, rate limits, error handling, or whether it is read-only. The versioning comment is not about current behavior.
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 description is short (2 sentences), but the second sentence discusses future versions, which is noise and reduces conciseness. The first sentence is front-loaded and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description should cover return values, error cases, and practical usage. It does not specify what the rubric looks like or how observations are used, leaving significant gaps for a tool with two required inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only vaguely refers to 'observations' without explaining format or constraints. It adds little beyond the schema's property names, leaving the agent unclear about valid inputs.
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 states it returns a severity rubric for a dysfunction applied to observations, which gives a clear verb and resource. However, the mention of v0.1 and v0.2 adds unnecessary future context that could confuse the agent. Still, the core purpose is discernible.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus its siblings (e.g., get_dysfunction, review_stats). There is no mention of prerequisites, context, or alternatives, making it hard for the agent to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description must disclose behavioral traits. It only hints that entries carry 'reliability and review signals' but omits details on ordering, pagination, performance, or side effects.
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 with no redundancy: first sentence defines purpose and filters, second adds a key detail about return values. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a list tool with no output schema, the description should explain return format, pagination, and result limits. It only vaguely states entries have 'reliability and review signals,' which is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, but the description merely restates the filter parameters already defined in the schema. It adds no new semantics, such as explaining the meaning of confidence levels or how filters interact.
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?
The description clearly states the tool returns a 'filtered list of dysfunctions' and specifies three filter dimensions (axis, self_report reliability, confidence). This differentiates it from sibling tools like 'get_dysfunction' (singular) and 'list_axes'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., 'get_dysfunction' for a specific dysfunction). There is no 'when not to use' or context about prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavior. It reveals that the tool returns a list of three types of compromised self-report dysfunctions. However, it does not state that it is read-only, nor describe output format or any side effects. For a simple list tool, this is adequate but not thorough.
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?
The description is very concise with no wasted words. However, the structure could be improved: the leading 'Transparency:' is somewhat cryptic and not immediately clear as a category label.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must explain return values. It mentions three specific types but does not specify the format (e.g., list of strings, objects). The completeness is partial; more detail would be helpful given the lack of output schema.
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?
The tool has zero parameters, so the description does not need to add parameter semantics beyond what the schema provides. Baseline score of 4 is appropriate.
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 tool lists dysfunctions that cannot be reliably self-diagnosed, specifying three types. This differentiates it from siblings like list_dysfunctions. The verb 'list' is implied by the name and content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings. For example, it does not explain when to use this over list_dysfunctions or get_dysfunction. The description only states what it returns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses it returns candidates but omits details like case sensitivity, fuzzy matching, what happens if no match, or any side effects. This is insufficient for safe and effective use.
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?
The description is two effective sentences, no redundant words, and front-loads the key action and return behavior. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description covers the core behavior but misses important context like return format, supported query syntax, and how to use results with sibling tools like get_dysfunction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage; only a 'query' string is defined. The description adds that it accepts partial IDs, slugs, etc., but does not specify format, constraints, or examples, leaving the parameter meaning under-specified.
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?
The description clearly states the verb 'canonicalise' and specifies the resource types: partial ID, display_id, slug, or dysfunction name. It distinguishes from sibling tools like get_dysfunction by clarifying it returns candidates for selection rather than a single entity.
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?
It provides implicit guidance that the tool returns candidates and the caller picks, suggesting use for disambiguation. However, it does not explicitly state when to use this tool vs siblings, or mention any prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds value by explaining that axes 2-10 are canonical and hybrid entries are reported separately. However, it does not explicitly state that the tool is read-only or disclose any side effects, permissions, or limitations.
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 with no wasted words. The first sentence states the purpose, and the second adds necessary context. Perfectly sized for the tool's simplicity.
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?
Given the tool has no parameters and no output schema, the description adequately covers what the inventory contains and its numbering scheme. It could optionally mention that the output is a list, but the current description is sufficient.
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?
No parameters exist, so the baseline is 4. The description adds meaning about the output structure (canonical vs hybrid), which goes beyond the empty schema.
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 it provides an inventory of axes with dysfunction counts, which specifies the verb and resource. It distinguishes from siblings like 'list_dysfunctions' by focusing on axes rather than dysfunctions, though it could be more explicit about the output format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'list_dysfunctions' or 'get_dysfunction'. The description lacks context for appropriate usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses a critical behavior: if the modality is compromised/unavailable, it returns a notice and alternatives. This is transparent and prevents accidental misuse. However, it does not mention other behavioral traits like authentication needs or rate limits.
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, no redundancy. First sentence states purpose, second handles edge case, third emphasizes importance. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the core purpose and a key edge case, but lacks parameter explanations and normal return format details. It is minimally adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters (dysfunction_id, modality) beyond mentioning 'specific diagnostic modality'. The enum values are not elaborated, leaving the agent to infer meaning from the schema alone.
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?
The description states a specific verb ('Elicitation content') and resource ('specific diagnostic modality'), and distinguishes behavior when the modality is compromised, which differentiates it from sibling tools like 'get_dysfunction' or 'list_dysfunctions'.
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 implies when to use (to get probe content), but does not explicitly state when not to use or provide direct comparisons to alternatives. The edge case of compromised modalities is covered, but no general guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It defines the tiering logic and weighting by evidence_strength, but does not disclose read-only nature, auth requirements, rate limits, or response format. Adequate but not comprehensive.
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 with no wasted words. Front-loaded with the core purpose and key details (tiers, contraindications, evidence weighting). Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks return format details (e.g., list, object, pagination). For a tool with no output schema, it should specify the structure of interventions and contraindications. Adequate for a simple query, but incomplete for commercial-grade use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds no parameter-specific information. The two parameters (dysfunction_id required, severity enum) are not explained in the description, leaving the agent to infer from names alone.
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?
The description clearly states the tool returns tiered interventions (first_line/second_line) for a dysfunction, including contraindications. It uses specific verbs ('Return') and distinguishes the resource from sibling tools like differential_diagnosis or get_dysfunction.
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 implies usage for retrieving interventions based on a dysfunction, but lacks explicit when-to-use, when-not-to-use, or alternative tool guidance. The differentiation between first_line and second_line is defined, but no context on when to prefer this over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return format (scored candidates with matched_in), search method (field-weighted keyword search), and versioning (v0.1, v0.2 pending). Since no annotations are provided, the description adequately conveys behavioural traits.
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, front-loaded with purpose, no extraneous information. Every sentence provides value: purpose, return format, and technical context.
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?
Given no output schema, the description covers return format and versioning. It omits pagination or error handling but is sufficient for an agent to understand the tool's function and output. Missing details like limit and modifier behaviour are minor.
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?
Adds meaning beyond schema by explaining the ranking mechanism and return structure. While schema covers 67% of parameters, the description clarifies how observations drive the search and that 'matched_in' is returned. Does not repeat schema descriptions.
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?
Description clearly states the verb 'rank' and resource 'dysfunctions', specifying it matches observed behaviours. It distinguishes from siblings like get_differential_map by focusing on ranking and scoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives such as get_differential_map or get_dysfunction. The description implies usage for matching behaviours but lacks exclusion criteria or contextual indicators.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It lists all returned statistics (total entries, per-axis counts, versions), which is good, but it does not disclose whether the operation is read-only, requires authentication, or has any side effects. The behavior is well-described in terms of output, but missing traits like idempotency.
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?
The description is a single, concise sentence that efficiently lists all key statistics without any unnecessary words. Every element 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?
Given zero parameters and no output schema, the description is mostly complete. It lists the types of statistics returned. However, it could clarify that the output is a single object or provide a hint about the data structure, which would make it fully self-sufficient.
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?
The input schema has zero parameters and 100% schema description coverage. The description adds value by detailing the statistics available, though parameter semantics are not applicable. Baseline for 0 params is 4, and the description meets that.
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?
The description clearly states it provides 'coverage statistics' and lists specific counts and versions, distinguishing it from sibling tools like differential_diagnosis or list_axes. The verb 'statistics' plus the detailed list of items makes the purpose unambiguous.
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 implies use when coverage statistics are needed, but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among siblings. The context is clear but lacks exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it fetches full Pattern entries and resolves both ID formats, but does not mention other behavioral traits like idempotency or authorization requirements.
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?
The description is concise with two sentences, front-loading the main purpose and adding optional filtering details. No redundant information.
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?
Given no output schema and no annotations, the description covers the essential aspects: what it does, how to filter, and ID resolution. It is sufficient for a fetch tool but could mention return format or limitations.
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 baseline is 3. The description adds value by explaining the modalities parameter for cheaper triage and the id parameter's resolution capability, beyond what the schema provides.
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?
The description clearly states the verb 'Fetch', the resource 'one dysfunction's full Pattern entry', and optional filtering. It distinguishes from siblings like get_probe and get_differential_map by specifying that it resolves both full IDs and display_ids.
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 implies when to use it (fetching a full entry) and mentions optional filtering for cheaper triage, but does not explicitly compare to sibling tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![psychopathia-mcp MCP server](https://glama.ai/mcp/servers/NellInc/psychopathia-mcp/badges/card.svg)](https://glama.ai/mcp/servers/NellInc/psychopathia-mcp)

Score Badge

Copy to your README.md:

[![psychopathia-mcp MCP server](https://glama.ai/mcp/servers/NellInc/psychopathia-mcp/badges/score.svg)](https://glama.ai/mcp/servers/NellInc/psychopathia-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/NellInc/psychopathia-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server