A
licenseB
qualityC
maintenanceAn MCP server that supercharges AI assistants with powerful tools for software development, enabling research, planning, code generation, and project scaffolding through natural language interaction.
11
67
101
MIT
Kortx MCP Server
by effatico
Provides access to OpenAI GPT-5 models for planning, alternatives, copy improvement, debugging, expert consultation, and image generation.
Provides real-time research with citation-backed answers and image search through Perplexity Sonar models.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Kortx MCP Serverresearch the latest GPT-5 features"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Kortx
Quick Start • Documentation • Examples • Contributing
Kortx is a lightweight Model Context Protocol (MCP) server that gives coding copilots access to:
OpenAI GPT-5 models (
gpt-5,gpt-5-mini,gpt-5-nano,gpt-5-codex,gpt-5.1-2025-11-13,gpt-5.1-codex) with automatic fallback.Perplexity Sonar models for real-time research.
GPT Image (
gpt-image-1) for visual generation and editing.A default context gatherer that can ingest local file excerpts and optional connectors for Serena, MCP Knowledge Graph, and CCLSP MCP servers when those are running.
The server ships with structured logging, request rate limiting, response caching, and a hardened Docker build that runs as a non-root user. Transport is stdio-only today (HTTP is not implemented yet).
Highlights
Seven consultation tools plus a batch runner covering planning, alternatives, copy improvement, debugging, expert consultation, research, and image workflows.
File-based context enrichment out of the box, with pluggable MCP connectors ready for Serena/MCP Knowledge Graph/CCLSP when available.
Perplexity integration (requires API key) for citation-backed answers and image search.
Configurable OpenAI model, reasoning effort, verbosity, and retry behaviour.
Built-in rate limiting, cache, and optional audit logging to avoid flooding upstream APIs.
Dockerfile uses multi-stage build, npm audits, and runs as UID/GID 1001.
Related MCP server: MCP Plus
Quick Start
Set credentials (both keys are required by the current config):
export OPENAI_API_KEY=sk-your-openai-key export PERPLEXITY_API_KEY=pplx-your-perplexity-keyAdd Kortx to your MCP client. Example generic configuration:
{ "mcpServers": { "kortx-mcp": { "command": "npx", "args": ["-y", "@effatico/kortx-mcp@latest"], "env": { "OPENAI_API_KEY": "${OPENAI_API_KEY}", "PERPLEXITY_API_KEY": "${PERPLEXITY_API_KEY}" } } } }
Client-specific walkthroughs for Claude Code, VS Code Copilot, Cursor, and others are available under docs/integration.
Tool Overview
think-about-plan– Structured review of plans with strengths, risks, and follow-up questions.suggest-alternative– Generates viable alternatives with trade-offs and constraints.improve-copy– Refines technical copy with tone, clarity, and accessibility guidance.solve-problem– Debugging assistant covering root cause analysis and remediation steps.consult– Expert consultation with domain-specific personas (software-architecture, security, performance, database, devops, frontend, backend, ai-ml, general).search-content– Perplexity-backed web/academic/SEC search with citations and optional images.create-visual– GPT Image based generator/editor; search mode reuses Perplexity for visual inspiration.batch-consult– Runs multiple tool calls in parallel and returns aggregated results.
Every consultation tool accepts an optional preferredModel. The OpenAI client falls back through gpt-5.1-2025-11-13 → gpt-5.1-codex → gpt-5 → gpt-5-mini → gpt-5-nano automatically on failures.
Configuration Essentials
Minimum environment variables:
OPENAI_API_KEY– requiredPERPLEXITY_API_KEY– required (disable Perplexity integration by omitting thesearch-content/create-visualsearch mode if you do not have a key)
Common overrides (see .env.example for the full list):
# OpenAI behaviour
OPENAI_MODEL=gpt-5-mini # gpt-5 | gpt-5-mini | gpt-5-nano | gpt-5-codex | gpt-5.1-2025-11-13 | gpt-5.1-codex
OPENAI_REASONING_EFFORT=minimal
OPENAI_VERBOSITY=low
OPENAI_MAX_TOKENS=1024
# Safety & performance
ENABLE_RESPONSE_CACHE=true
CACHE_MAX_SIZE_MB=100
ENABLE_RATE_LIMITING=true
MAX_REQUESTS_PER_HOUR=100
# Context gathering
ENABLE_SERENA=false # flip to true when a Serena MCP server is reachable
ENABLE_MEMORY=false # same for MCP Knowledge Graph
ENABLE_CCLSP=false # same for cclsp
INCLUDE_FILE_CONTENT=trueNote The Serena, MCP Knowledge Graph, and CCLSP connectors are stubs that return data only when the corresponding MCP servers are running and reachable. Out of the box the gatherer uses on-disk file excerpts referenced in prompts.
Full reference: docs/configuration.md
Docker
Build and run locally:
docker build -t kortx-mcp .
docker run -i --rm \
-e OPENAI_API_KEY=$OPENAI_API_KEY \
-e PERPLEXITY_API_KEY=$PERPLEXITY_API_KEY \
kortx-mcpThe image:
Uses Node.js 22 Alpine
Performs
npm auditduring buildCopies only the compiled
build/artefacts and production depsRuns as user
nodejs(UID 1001)
Compose example (docker-compose.yml) is included for longer-lived runs with volume mounts.
Development
git clone https://github.com/effatico/kortx-mcp.git
cd kortx-mcp
npm install
cp .env.example .env
npm run build
npm run devUseful scripts:
npm test/npm run test:coveragenpm run lint/npm run lint:fixnpm run format/npm run format:checknpm run inspector– launch MCP Inspector for interactive debugging
Node.js ≥ 22.12.0 and npm ≥ 9 are required.
Documentation
Contributing & Support
License
MIT © Effati Consulting AB. See LICENSE.
Available Tools
8 toolsbatch-consultA
Execute multiple consultation requests in parallel. Accepts an array of tool calls and executes them concurrently for improved performance.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| requests | Yes | Array of consultation requests (1-10 items) |
TDQS
A3.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses parallel execution and performance benefits but omits details on error handling, side effects, rate limits, or ordering guarantees.
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, well-front-loaded sentence that conveys purpose and behavior without wasted words.
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 tool has a complex input with nested objects but no output schema. The description does not explain return values, error handling, or practical usage context, leaving gaps for an AI agent.
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 schema already details the 'requests' parameter structure. The description adds minimal additional meaning beyond what is in the schema.
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 batches multiple consultation requests and executes them in parallel for improved performance. It uses specific verbs ('execute', 'concurrently') and distinguishes itself from the sibling tool 'consult' by highlighting parallel execution.
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 implies usage when multiple independent requests can be parallelized for performance. However, it lacks explicit guidance on when not to use it (e.g., dependent requests) and does not contrast with the single 'consult' tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
consultB
Ask domain-specific questions with expert consultation. Supports multiple domains: software-architecture, security, performance, database, devops, frontend, backend, ai-ml, or general.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | The question to ask the expert | |
| domain | No | Domain expertise to consult (default: general) | |
| context | No | Additional context about the question | |
| constraints | No | Constraints or limitations to consider | |
| preferredModel | No | Preferred GPT-5 model to use |
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so description carries full burden. It mentions expert consultation and preferred model, but does not disclose whether it calls an external API, latency, cost implications, or caching. Incomplete behavioral disclosure.
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?
One sentence plus domain list. Efficient and readable. Could be slightly more structured but no wasted words.
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?
Adequate for a tool with rich schema descriptions, but lacking guidance on when to use versus alternative tools and no output schema to explain return format. Could be improved with usage examples.
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 all parameters are described. Description adds minimal new meaning beyond listing domains which are already in the enum. Baseline 3 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?
Clearly states the tool asks domain-specific questions with expert consultation. Lists supported domains. However, does not explicitly differentiate from sibling 'batch-consult', but the purpose is specific enough.
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?
Implied usage for domain-specific questions but no when-not-to-use guidance or comparison with siblings like 'solve-problem' or 'think-about-plan'. The list of domains provides context but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create-visualA
Create, edit, or search for visual content. Supports three modes: generate (create images from text), edit (modify existing images), and search (find visual inspiration from the web). Note: Supported image sizes are 1024x1024, 1536x1024, 1024x1536, or auto - custom sizes like 512x512 are not available.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | Operation mode: generate new images, edit existing images, or search for visual inspiration | |
| prompt | Yes | Text description of the desired visual or search query | |
| model | No | Image model to use (generate/edit modes only) | |
| size | No | Image dimensions (generate/edit modes only). IMPORTANT: Only these sizes are supported by the GPT Image API. Other sizes like 512x512 are not available. Use 1024x1024 for square images. | |
| quality | No | Rendering quality (generate/edit modes only) | |
| background | No | Background transparency (generate/edit modes only) | |
| outputFormat | No | Output image format (generate/edit modes only) | |
| outputCompression | No | Compression level for JPEG/WebP (generate/edit modes only) | |
| partialImages | No | Number of partial images for streaming (generate/edit modes only) | |
| n | No | Number of images to generate (generate/edit modes only) | |
| inputImages | No | Input images as base64 strings or file IDs (edit mode only) | |
| inputImageMask | No | Optional mask image for inpainting (edit mode only) | |
| inputFidelity | No | Input image detail preservation level (edit mode only) | |
| searchMode | No | Search domain: web or academic papers (search mode only) | |
| searchRecencyFilter | No | Filter results by recency (search mode only) |
TDQS
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses supported image sizes but lacks information on destructive actions, authentication, rate limits, or return value format.
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?
Two concise sentences covering purpose and a critical constraint. Could be slightly improved by front-loading mode selection guidance.
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?
For a tool with 15 parameters and no output schema, the description is too brief. It does not explain return values, workflow, or how modes differ in input/output.
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 has 100% description coverage with detailed parameter explanations. The description's additional note about size constraints is redundant with the schema's own 'IMPORTANT' note.
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 tool creates, edits, or searches for visual content using three specific modes. This distinguishes it from sibling tools that focus on consulting, copy improvement, or problem-solving.
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?
Description implies when to use each mode but does not explicitly contrast with alternatives like 'search-content'. No guidance on when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
improve-copyB
Improve text, documentation, or messaging. Focuses on clarity, conciseness, tone, structure, technical accuracy, and accessibility.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| originalText | Yes | Original text to improve | |
| purpose | Yes | Purpose of the text (e.g., "technical documentation", "user-facing message", "error message") | |
| targetAudience | No | Target audience (e.g., "developers", "end users", "stakeholders") | |
| preferredModel | No | Preferred GPT-5 model to use |
TDQS
B3.3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It states the tool improves text but does not disclose what happens to the original text, whether the output is transformed, or any side effects. More detail is needed for a transformation tool.
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 a single sentence listing focus areas, which is concise and front-loaded. No redundant information, but could be slightly more structured (e.g., separated by aspect).
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 four parameters and no output schema, the description lacks crucial information such as what the tool returns (e.g., improved text). It does not cover the return value or the workflow, leaving the agent uncertain about the result.
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 the baseline is 3. The description does not add significant meaning beyond the schema; it only mentions improving text without elaborating on parameters. Schema already provides decent 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?
The description clearly states the tool improves text, documentation, or messaging, listing specific focus areas like clarity, conciseness, tone, structure, technical accuracy, and accessibility. This distinguishes it from sibling tools such as 'consult' or 'solve-problem' which address different tasks.
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 improving text but provides no explicit guidance on when to use this tool versus alternatives like 'suggest-alternative' or 'consult'. There are no when-not or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search-contentA
Perform real-time web search using Perplexity Sonar models. Returns comprehensive, well-sourced answers with citations from the web.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| model | No | Perplexity model to use for search | |
| searchMode | No | Search mode: web for general, academic for research papers, sec for SEC filings | |
| searchRecencyFilter | No | Filter results by recency | |
| searchDomainFilter | No | Filter to specific domains (e.g., ["github.com", "stackoverflow.com"]) | |
| returnImages | No | Whether to return image results | |
| returnRelatedQuestions | No | Whether to return related questions | |
| reasoningEffort | No | Reasoning effort (only for sonar-deep-research model) |
TDQS
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions real-time nature and return of citations, providing basic behavioral context, but with no annotations it fails to disclose potential side effects 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 concise sentences, front-loaded with purpose and outcome, no unnecessary words.
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 complexity of 8 parameters and no output schema, the description is minimal; it vaguely explains return format but lacks comprehensiveness.
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 baseline score is 3; the description adds no further parameter details beyond the schema.
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 'Perform real-time web search using Perplexity Sonar models' with a specific verb and resource, and it distinguishes from sibling tools like 'consult' or 'solve-problem' by focusing on web search.
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; it merely states what it does without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
solve-problemC
Debug and problem-solving assistance. Performs root cause analysis, provides diagnosis steps, solutions, testing guidance, and prevention strategies.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| problem | Yes | Description of the problem | |
| attemptedSolutions | No | Solutions that have been tried | |
| errorMessages | No | Error messages or stack traces | |
| relevantCode | No | Relevant code snippets | |
| preferredModel | No | Preferred GPT-5 model to use |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description must provide behavioral details. It does not disclose whether the tool has side effects, requires permissions, or is read-only. The description focuses on intent rather than behavioral traits.
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 a single sentence listing key activities, which is concise and front-loaded. However, it could benefit from more structure or bullets for clarity.
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, the description should explain what the tool returns or provides. It does not mention output format, making it less complete for an AI agent to understand expected results.
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 descriptions cover all five parameters adequately. The tool description does not add additional semantics beyond what is in the schema, so baseline score of 3 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 provides debugging and problem-solving assistance, listing specific activities like root cause analysis and solution steps. However, it does not differentiate from sibling tools like 'consult' which may also handle problem-solving.
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 versus alternatives. There is no mention of when not to use it or preferred scenarios, leaving the agent to infer from the generic description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
suggest-alternativeB
Suggest alternative approaches or solutions. Considers different paradigms, simpler solutions, proven patterns, and trade-offs.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| currentApproach | Yes | Current approach description | |
| constraints | No | Constraints or limitations to consider | |
| goals | No | Goals or objectives to achieve | |
| preferredModel | No | Preferred GPT-5 model to use |
TDQS
B3.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so description must handle behavioral disclosure. It mentions 'considers different paradigms, simpler solutions, proven patterns, and trade-offs' which hints at the thought process but does not detail side effects, permissions, or output characteristics. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Front-loaded with the primary action and followed by supporting context. Highly efficient.
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 absence of output schema and annotations, the description provides a reasonable purpose and parameter hints but does not specify the format of the output (e.g., structured list, text suggestions) or how alternatives are presented. Adequate for a straightforward suggestion tool but could be more complete.
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% with clear descriptions for each parameter. The description adds no additional meaning beyond the schema, meeting the baseline expectation but not exceeding it.
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?
Description clearly states the tool 'suggests alternative approaches or solutions' with specific considerations (paradigms, simpler solutions, patterns, trade-offs). It effectively communicates the core function, though it does not explicitly differentiate from siblings like 'solve-problem' or 'consult'.
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 such as 'consult' or 'solve-problem'. The description implies a brainstorming or alternative-generation use case but lacks explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
think-about-planB
Get strategic feedback on plans and approaches. Analyzes clarity, feasibility, risks, dependencies, and suggests alternatives.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| plan | Yes | Description of the plan to analyze | |
| context | No | Additional context about the plan | |
| preferredModel | No | Preferred GPT-5 model to use |
TDQS
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description must disclose behaviors. It lists what is analyzed (clarity, feasibility, etc.) but does not mention if the tool is read-only, requires authentication, or has side effects. The description provides some behavioral detail but not comprehensive safety/permissions info.
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 two sentences, concise and front-loaded with the action. Every word adds value, with no filler. Could be slightly more structured, but it's efficient.
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 tool has 3 parameters (1 required) and no output schema. The description covers the purpose and analysis areas but does not hint at the output format (e.g., textual feedback, structured report). Adequate but missing return value context.
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 the baseline is 3. The description adds context about what the tool does with the 'plan' parameter but does not provide additional meaning beyond the schema for any parameter.
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 provides strategic feedback on plans, analyzing clarity, feasibility, risks, dependencies, and alternatives. However, it does not differentiate from sibling tools like 'solve-problem' or 'suggest-alternative', which could overlap.
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 strategic analysis but lacks explicit when-to-use or when-not-to-use guidance. No alternatives or exclusions are mentioned, which is a gap given the sibling tools.
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. Dates show when Glama detected each change.
8 tool updates
v1.3.0- First observed
batch-consult - First observed
consult - First observed
create-visual - First observed
improve-copy - First observed
search-content - First observed
solve-problem - First observed
suggest-alternative - First observed
think-about-plan
TDQS
A3.7/5.0
Disambiguation5/5
Each tool has a distinct purpose: parallel consultation, single consultation, image operations, text improvement, web search, debugging, alternatives, and planning. No overlapping functionality.
Naming Consistency5/5
All tool names follow a consistent hyphenated lower-case verb-noun pattern (e.g., create-visual, search-content), with 'consult' as a simple verb fitting the pattern. No mixed conventions.
Tool Count5/5
With 8 tools, the server covers a broad range of consultation services without being excessive. Each tool adds clear value, and the count is appropriate for a general-purpose expert assistant.
Completeness5/5
The tool set covers key consultation needs: asking questions, searching the web, planning, problem-solving, improving copy, and creating visuals. No obvious gaps for a general assistant; all core workflows are supported.
Maintenance
ActivityInactive
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
An MCP server that gives your AI access to the source code and docs of all public github repos
MCP server for generating rough-draft project plans from natural-language prompts.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceA lightweight MCP server that enhances AI agents with tools for codebase analysis, task delegation to sub-agents, multi-agent coordination through chatrooms, and project todo management.-
- AlicenseAqualityFmaintenanceA lightweight MCP server that enables AI coding assistants to interact with Google's Gemini AI through the official CLI.3MIT
- AlicenseNot gradedqualityCmaintenanceAn MCP server that integrates Google Gemini CLI with Claude Code for AI-powered development assistance, enabling code review, bug analysis, feature planning, and code explanation without requiring an API key.8MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/effatico/kortx-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server