agenttune

Server Details

Personality tuning files for AI agents: 43 MIT-licensed tunings + 5 inline personality tests.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 48 days
Last Tested: 2026-10-04 19:15
Transport: Streamable HTTP · MCP 2025-06-18
URL
Repository: bernardjhuang/agenttune
GitHub Stars: 0

TDQS

A4/5.0

Scored 2026-09-26 19:45 across 6 tools

Disambiguation4/5

Each tool targets a distinct object: free-tools documentation, page resources, test specs, or tuning files. The only mild overlap is between get_free_tools and list_resources since both return catalog-like content, but the descriptions clarify their different scopes.

Naming Consistency5/5

All tool names follow a predictable get_* or list_* + noun pattern. Singular and plural usage aligns with the returned object type, and there is no mixing of naming conventions.

Tool Count5/5

Six tools is well-scoped for a read-only reference server. Each tool has a clear retrieval or listing purpose, and the count feels neither thin nor bloated.

Completeness5/5

The server provides complete coverage of its apparent domain: listing and fetching resources, listing and fetching tunings, retrieving test specifications, and accessing local API documentation. There are no obvious missing operations or dead ends for the stated purpose.

Available Tools

6 tools

get_free_toolsDiscover AgentTune’s eight free toolsA

Read-only

Inspect

Return the free browser tools catalog, destination registry, and local JavaScript API documentation. No personal data is accepted. Download the functions to process instructions locally; this call does not run models or install preferences.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`tools`	Yes
`version`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds valuable behavioral detail: no personal data is accepted, it returns three specific content types, and it has no side effects like running models or installing preferences.

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 the main return object front-loaded. Every sentence provides distinct value: what is returned, data handling, and side-effect guarantees. No padding or redundant restating of the tool name.

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

Completeness5/5

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

With zero parameters and an output schema present, the description fully covers what this read-only tool returns and what it avoids doing. An agent has enough information to invoke it correctly without further inference.

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, and the schema fully documents that with an empty properties object. The description adds no parameter semantics, which is appropriate; the baseline for zero-parameter tools is 4.

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 uses a specific verb 'Return' and lists concrete resources: the free browser tools catalog, destination registry, and local JavaScript API documentation. It clearly differentiates from the tuning/test siblings by describing a read-only informational catalog rather than any tuning operation.

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?

It gives clear context: the agent should call this to download functions for local instruction processing. It also states exclusions ('does not run models or install preferences'), though it does not explicitly name sibling alternatives or provide when-not-to-use conditions.

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

get_resourceRead a guide or research articleA

Read-only

Inspect

Retrieve one page-specific Markdown resource by the exact ID from list_resources; includes provenance and evidence status.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`url`	Yes
`body`	Yes
`markdown`	Yes
`revision`	Yes
`evidence_status`	Yes

TDQS

A4.5/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 adds useful behavioral context: the result is Markdown, page-specific, and includes provenance and evidence status. No edge cases are mentioned, but with read-only semantics and an output schema present, the description carries adequate transparency.

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, front-loaded sentence that states the action, target, source of the ID, output format, and included metadata. Every phrase adds value and there is no filler or redundancy.

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

Completeness5/5

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

For a one-parameter, read-only tool with an output schema, the description is complete: it tells the agent what to call, where the ID comes from, what the response looks like, and what additional content it contains. Nothing essential is missing.

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?

With no parameter descriptions in the schema, the description compensates by explaining that the id must be the exact ID from list_resources. This gives the agent enough semantic grounding to supply a correct value, even though it does not describe the format or expected length.

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 ('Retrieve'), the resource ('one page-specific Markdown resource'), and the key constraint ('by the exact ID from list_resources'). It also distinguishes itself from list_resources by specifying that it fetches a single item rather than enumerating resources.

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?

The description indicates that the ID must come from list_resources, which implies the correct workflow: call list_resources first, then get_resource with the exact ID. It does not explicitly name alternatives or when-not-to-use scenarios, but the stated source and exact-ID requirement provide clear usage context.

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

get_test_specGet questionnaire availability and specificationA

Read-only

Inspect

Fetch a complete questionnaire specification for mbti (32 items), enneagram (36), disc (16), attachment (36) or big-five (50). All five are available, with exact instrument/version IDs, response anchors and strict scoring instructions. The first four preserve the legacy AgentTune adaptations; instrument-specific source terms apply. Administer only when requested, keep responses local, preserve ties, and let users review any suggested communication preferences before installation.

ParametersJSON Schema

Name	Required	Description	Default
`test`	Yes	Which test instrument.

Output Schema

ParametersJSON Schema

Name	Required	Description
`body`	Yes
`test`	Yes
`status`	Yes
`revision`	Yes
`available`	Yes
`markdown_url`	Yes
`canonical_url`	Yes
`instrument_id`	Yes
`evidence_status`	Yes
`instrument_version`	Yes

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses important behavioral expectations: preserving legacy AgentTune adaptations, applying instrument-specific source terms, keeping responses local, preserving ties, and requiring user review before installation. This adds meaningful operational context that annotations alone do not provide.

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 front-loaded with the primary action and resource, then adds necessary detail about instrument-specific behavior and usage constraints. It is slightly dense with multiple clauses, but every sentence contributes useful information without redundancy.

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

Completeness5/5

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

For a single-parameter read-only tool with an output schema, the description covers what the tool returns, which instruments are available, important behavioral rules, and prerequisites for use. Nothing essential for an agent to invoke this tool correctly is missing.

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% and the parameter description already documents the enum. The tool description adds value by specifying item counts per instrument, noting the legacy adaptations for the first four, and indicating that exact IDs and scoring instructions are included in the result. This goes beyond the schema's minimal 'Which test instrument.'

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 opens with a specific verb and resource: 'Fetch a complete questionnaire specification' and enumerates the exact instruments (mbti, enneagram, disc, attachment, big-five) with item counts. This clearly distinguishes it from sibling tools like list_resources or get_tuning, which focus on different resources.

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?

The description provides clear context by stating 'Administer only when requested' and instructs on how to handle responses and user preferences. It does not explicitly name alternative tools or when-not-to-use conditions relative to siblings, but the usage context for this specific tool is sufficiently clear.

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

get_tuningGet a tuning file (paste-ready Markdown)B

Read-only

Inspect

Fetch one tuning file as Markdown with YAML front-matter. The front-matter links to the shared platform registry and installation protocol. structuredContent.body is the preference text; metadata stays separate. Confirmation of saved text is distinct from evaluation of behavior. MIT licensed.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	Type slug, lowercase. mbti: 4-letter code (intj). enneagram: N-name (5-investigator). disc: letter-name (d-dominance). attachment: style (secure). ocean: dimension-pole (openness-high). Unsure? Call list_tunings.
`system`	Yes	Personality system.

Output Schema

ParametersJSON Schema

Name	Required	Description
`body`	Yes
`slug`	Yes
`system`	Yes
`body_url`	Yes
`revision`	Yes
`canonical_url`	Yes
`evidence_status`	Yes
`install_protocol`	Yes
`metadata_markdown`	Yes

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, and the description does not contradict that. It adds context about the output structure (structuredContent.body vs metadata) and a semantic nuance (confirmation vs evaluation), but does not disclose potential side effects, authentication, or rate limits. Since annotations cover the read-only nature, the added context is modest.

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 three sentences and front-loads the core purpose. It includes a note about licensing that is not essential for invocation, but the overall length is appropriate and there is minimal fluff.

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 read-only fetch with an output schema, the description explains the output format and separates metadata from content. It does not cover error handling or pagination, but these are not critical for this tool's usage, and the schema and annotations cover the rest.

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 both parameters (system and slug) are already fully documented. The description does not add any additional meaning or syntax details beyond what the schema provides, so the baseline of 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 description states a clear verb ('Fetch') and resource ('tuning file') with an explicit format (Markdown with YAML front-matter). It distinguishes the tool's scope from generic operations, though it does not explicitly name sibling tools like list_tunings for contrast.

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 such as list_tunings. The schema's slug description suggests calling list_tunings when unsure, but the description itself offers no usage context or exclusions.

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

list_resourcesFind guides and researchA

Read-only

Inspect

Search the versioned catalog of setup guides, templates, protocols and research. Returns canonical URLs, Markdown URLs, revisions and evidence status.

ParametersJSON Schema

Name	Required	Description	Default
`kind`	No
`query`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`version`	Yes
`resources`	Yes

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=true and openWorldHint=false, so the description does not need to restate safety. It adds useful behavioral context by noting the catalog is versioned and that results include 'canonical URLs, Markdown URLs, revisions and evidence status', which goes beyond the structured annotations.

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 tight sentences: the first states the action and resource, the second states the return value highlights. There is no filler, and the most important information is front-loaded.

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?

For a simple read-only list tool with an output schema and only two optional parameters, the description is adequate but not complete. It fails to explain how the 'kind' filter maps to catalog content, what 'query' does, or how this tool relates to sibling list/get tools, leaving an agent to infer important selection and usage details.

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 0%, so the description must compensate for undocumented parameters. It does not explain the 'query' parameter at all, and only loosely aligns 'kind' with the mention of 'guides' and 'research'. The 'templates' and 'protocols' terms do not directly map to the enum values, leaving parameter meaning underspecified.

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 uses a specific verb ('Search') and identifies the resource ('versioned catalog of setup guides, templates, protocols and research'). It clearly communicates that this tool finds/list resources, which separates it from 'get_resource' (singular fetch) by implying a search/listing behavior, though it does not explicitly name sibling differentiation.

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 phrase 'Search the versioned catalog' implies that the tool is for searching or listing resources, providing some usage context. However, there is no explicit guidance on when to prefer this over sibling tools like 'get_resource' or 'list_tunings', and no exclusion criteria or alternative recommendations are given.

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

list_tuningsList all personality tuningsA

Read-only

Inspect

Catalog of all 43 AgentTune personality tuning files (slug, code, name, one-line blurb), optionally filtered by system. Use it to resolve a user's personality type to the right slug before calling get_tuning.

ParametersJSON Schema

Name	Required	Description	Default
`system`	No	Optional filter: one of the five personality systems.

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes
`license`	Yes
`tunings`	Yes
`next_step`	Yes

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 by calling the tool a catalog and noting it returns 'all 43' files. It adds concrete behavioral context beyond annotations: the finite count, the fields returned, and the optional system filter, which sets expectations for a lightweight listing operation.

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, front-loaded with the core purpose, followed by a practical usage note. No filler or redundant restatement of the schema; each sentence earns its place.

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

Completeness5/5

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

For a read-only, optional-filter list tool with a complete parameter schema and an output schema, the description is sufficient. It tells the agent what is returned, when to use it, and how it relates to get_tuning, leaving no critical gap for correct invocation.

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%, and the only parameter 'system' is fully described in the schema with an explicit enum. The description merely mentions 'optionally filtered by system' without adding any semantic detail not already in the schema, so baseline 3 applies.

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 uses a specific verb ('Catalog') with a precise resource ('all 43 AgentTune personality tuning files') and enumerates the returned fields (slug, code, name, one-line blurb). It also names get_tuning as the downstream tool, differentiating itself from that sibling without ambiguity.

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?

The description gives an explicit usage directive: 'Use it to resolve a user's personality type to the right slug before calling get_tuning.' It does not explicitly list exclusions or alternatives like list_resources, but the primary intended workflow is clear.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateSep 26, 2026

Changedget_test_spec5 fields changed

addedOutput schema / properties / available
```
Added value: +{
+  "type": "boolean"
+}
```

addedOutput schema / properties / instrument_id

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / instrument_version

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / status
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / required

Previous value: -[
-  "test",
-  "canonical_url",
-  "markdown_url",
-  "body",
-  "revision",
-  "evidence_status"
-]New value: +[
+  "status",
+  "available",
+  "instrument_id",
+  "instrument_version",
+  "test",
+  "canonical_url",
+  "markdown_url",
+  "body",
+  "revision",
+  "evidence_status"
+]

5 tool updatesSep 26, 2026

Addedget_resource

Changedget_test_spec1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "body": {
+      "type": "string"
+    },
+    "canonical_url": {
+      "type": "string"
+    },
+    "evidence_status": {
+      "type": "string"
+    },
+    "markdown_url": {
+      "type": "string"
+    },
+    "revision": {
+      "type": "string"
+    },
+    "test": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "test",
+    "canonical_url",
+    "markdown_url",
+    "body",
+    "revision",
+    "evidence_status"
+  ],
+  "type": "object"
+}

Changedget_tuning1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "body": {
+      "type": "string"
+    },
+    "body_url": {
+      "type": "string"
+    },
+    "canonical_url": {
+      "type": "string"
+    },
+    "evidence_status": {
+      "type": "string"
+    },
+    "install_protocol": {
+      "type": "string"
+    },
+    "metadata_markdown": {
+      "type": "string"
+    },
+    "revision": {
+      "type": "string"
+    },
+    "slug": {
+      "type": "string"
+    },
+    "system": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "system",
+    "slug",
+    "canonical_url",
+    "body_url",
+    "revision",
+    "evidence_status",
+    "body",
+    "metadata_markdown",
+    "install_protocol"
+  ],
+  "type": "object"
+}

Addedlist_resources

Changedlist_tunings1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "count": {
+      "type": "integer"
+    },
+    "license": {
+      "type": "string"
+    },
+    "next_step": {
+      "type": "string"
+    },
+    "tunings": {
+      "items": {
+        "properties": {
+          "blurb": {
+            "type": "string"
+          },
+          "body_url": {
+            "type": "string"
+          },
+          "canonical_url": {
+            "type": "string"
+          },
+          "code": {
+            "type": "string"
+          },
+          "evidence_status": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "revision": {
+            "type": "string"
+          },
+          "slug": {
+            "type": "string"
+          },
+          "system": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "system",
+          "slug",
+          "canonical_url",
+          "body_url",
+          "revision",
+          "evidence_status"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "count",
+    "license",
+    "next_step",
+    "tunings"
+  ],
+  "type": "object"
+}

1 tool updateSep 26, 2026
- Addedget_free_tools
3 tool updatesJun 10, 2026
- First observedget_test_spec
- First observedget_tuning
- First observedlist_tunings

Related MCP Connectors

OriginGrid A
net.origingrid
AI Agent Source Registry. 288K+ curated sources for agentic search and discovery.
Search Agent Orchestration
191
StudioMeyer CrewOAuth
io.studiomeyer
Agent personas for Claude. 16 tools, 13 personas, 3 workflows. Zero extra API cost. Free.
Autonomous Agents Agent Orchestration
2
marz-greta-lock-network B
dev.replit.kirk.91eaaf4b-0a31-4f81-971a-86dc09a31986-00-2a9kujnvh541f-mwardvi0
Human-likeness scoring of AI text vs 12 real personality profiles; free tools + x402 paid tier
AI & Machine Learning Research & Data
81
IA-QA — 130+ QA & Dev Tools for AI Agents B
io.github.JcJamet
130+ QA & dev tools for AI agents: prompt injection, RAG testing, VLM eval, guardrails. Free.
Testing & QA Tools AI & Machine Learning
1522

Related MCP Servers

personality-test-mcp
Education & Learning Tools AI & Machine Learning
devshark
A
license
Not graded
quality
D
maintenance
Enables AI models to administer personality tests, score responses, and provide personality type assessments, with optional integration with Ollama for personalized AI interactions.
Updated a year ago (2025-04-12 16:11 UTC)
1
ISC
mcp-crew
studiomeyer-io
A
license
Not graded
quality
Not graded
maintenance
Agent Personas for Claude. 10 tools, 8 personas, 3 workflows. Zero API cost.
Updated 5 months ago (2026-04-25 03:49 UTC)
-
five-mcp
AI & Machine Learning Developer Tools
kiro0x
A
license
A
quality
A
maintenance
LLM character consistency engine — generates structured JSON constraints from 4 questions about your AI's psychology. Drop into any LLM's system prompt to prevent persona drift; reduces inference cost from retries.
Updated 3 months ago (2026-07-12 15:20 UTC)
1
40 PyPI
6
MIT
genpark-agent-dynamic-persona
Agent Orchestration Communication Autonomous Agents
alphaparkinc
A
license
Not graded
quality
B
maintenance
Enables AI agents to dynamically adjust their communication formality, brevity, tone, and technical depth based on channel context, the user's cognitive load, and sentiment feedback. It runs as a zero-dependency MCP server that generates contextually appropriate persona-styled responses and message rewrites.
Updated 20 hours ago (2026-10-03 23:51 UTC)
7
MIT

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Server Details

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources