Just Prompt

by disler

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
There is significant overlap between 'prompt', 'prompt_from_file', and 'prompt_from_file_to_file', all centered on sending prompts to multiple models, which could cause confusion. However, 'ceo_and_board' adds a distinct decision-making layer, and 'list_models' and 'list_providers' are clearly separate informational tools, helping to mitigate ambiguity.
Naming Consistency4/5
Most tools follow a clear verb_noun or verb_from_noun pattern (e.g., 'list_models', 'prompt_from_file'), with consistent snake_case throughout. The only deviation is 'ceo_and_board', which uses a noun-based name that breaks the verb-led convention, but it's still readable and not chaotic.
Tool Count5/5
With 6 tools, this server is well-scoped for its purpose of managing and prompting LLM models. The count is sufficient to cover core functionalities like listing providers/models and various prompting methods without being overwhelming or too sparse.
Completeness4/5
The toolset covers key operations for LLM interaction: listing providers and models, basic prompting, file-based prompting, and an advanced decision-making tool. A minor gap exists in lacking update or delete operations for prompts or models, but agents can likely work around this for typical use cases.
Average 3.1/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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.
Add a glama.json file to provide metadata about your server.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a list operation (implied read-only) but doesn't disclose important behavioral traits like whether it requires authentication, rate limits, pagination behavior, error handling, or what format the returned models list will have. The description is minimal and lacks operational context.
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, efficient sentence that directly states the tool's purpose without unnecessary words. However, it could be more front-loaded with critical information about behavioral aspects given the lack of annotations.
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 no annotations, no output schema, and minimal description, the contextual information is insufficient. The description doesn't explain what 'available models' means (e.g., supported models, all models including deprecated ones), doesn't describe the return format, and provides no error handling or authentication 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?
The schema description coverage is 100%, so the input schema already fully documents the single 'provider' parameter with examples. The description adds no additional parameter semantics beyond what's in the schema, maintaining the baseline score of 3 for adequate coverage when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all available models') and the target resource ('for a specific LLM provider'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'list_providers' which might be conceptually related but serves a different function.
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?
The description provides no guidance on when to use this tool versus alternatives, prerequisites, or contextual constraints. It mentions 'specific LLM provider' but doesn't explain how to determine which provider to use or what happens if an invalid provider is specified.
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 provided, the description carries the full burden of behavioral disclosure. It states the action ('send a prompt') but lacks details on what happens: e.g., how models are selected, whether responses are returned or stored, any rate limits, authentication needs, or error handling. This is a significant gap for a tool interacting with external LLMs.
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, efficient sentence with zero waste. It's front-loaded and directly states the tool's function without unnecessary elaboration, making it highly concise and well-structured.
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 the complexity of interacting with multiple LLM models, no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like response format, error handling, or model selection logic, leaving gaps that could hinder effective tool use by 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 description coverage is 100%, so the schema fully documents both parameters. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain the 'models_prefixed_by_provider' format further or provide examples beyond the schema's description). Baseline 3 is appropriate as the schema handles parameter documentation.
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 'Send a prompt to multiple LLM models' clearly states the action (send) and resource (prompt to LLM models), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'prompt_from_file' or 'prompt_from_file_to_file', which also involve sending prompts but with different input methods.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over 'prompt_from_file' (for file-based prompts) or 'prompt_from_file_to_file' (for file-to-file processing), nor does it specify any prerequisites or exclusions for usage.
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 carries the full burden. It discloses the need for absolute paths and mentions the CEO decision process, but lacks details on behavioral traits such as error handling, rate limits, authentication needs, or what the output looks like (e.g., file formats, decision format). For a tool with 4 parameters and no annotations, this is a significant gap in transparency.
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 appropriately sized with two sentences: the first explains the core functionality, and the second provides a critical usage note. It's front-loaded with the main purpose, and the 'IMPORTANT' section adds necessary guidance without redundancy. However, the second sentence could be integrated more smoothly, slightly affecting structure.
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 the tool's complexity (multi-model decision-making with file I/O), no annotations, and no output schema, the description is incomplete. It doesn't explain the output format, how the CEO decision is derived, error cases, or dependencies on other tools. For a tool with this functionality, more context is needed to ensure proper usage by 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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by emphasizing absolute paths in a note, but doesn't provide additional semantic context like examples or rationale for parameter choices. With high schema coverage, the baseline is 3, and the description meets this without compensating further.
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's purpose: 'Send a prompt to multiple 'board member' models and have a 'CEO' model make a decision based on their responses.' It specifies the verb ('send'), resource ('prompt'), and outcome ('CEO model make a decision'), distinguishing it from simpler prompt tools like 'prompt' or 'prompt_from_file'. However, it doesn't explicitly differentiate from 'prompt_from_file_to_file' which also involves file-based prompting with output.
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 when needing multi-model consensus with a CEO decision-maker, as opposed to single-model prompts. It includes an 'IMPORTANT' note about absolute paths, which provides some context. However, it doesn't explicitly state when to use this tool versus alternatives like 'prompt_from_file_to_file' or under what scenarios the board/CEO metaphor is beneficial, leaving usage somewhat implied rather than clearly defined.
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 provided, the description carries full burden for behavioral disclosure. It states what the tool does but provides no information about permissions needed, rate limits, pagination behavior, response format, or whether this is a read-only operation. For a tool with zero annotation coverage, this leaves significant behavioral gaps unaddressed.
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, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple list operation and front-loads the essential information. Every word earns its place in this minimal description.
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 the tool has no annotations, no output schema, and the description provides only basic purpose information, there are significant completeness gaps. For even a simple list operation, the description should address response format, potential limitations, or behavioral context. The current description is insufficient for a tool that agents need to understand fully before invocation.
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 with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters since none exist. This earns a baseline score of 4 for parameter semantics when there are no parameters to document.
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 verb ('List') and resource ('all available LLM providers'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'list_models', but the resource specificity (providers vs models) provides implicit differentiation. The description avoids tautology by not just restating the tool name.
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?
The description provides no guidance on when to use this tool versus alternatives like 'list_models' or other sibling tools. It doesn't mention prerequisites, context for usage, or any exclusions. While the purpose is clear, there's no explicit usage guidance beyond the basic action described.
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 provided, the description carries full burden for behavioral disclosure. It mentions the absolute path requirement (a constraint) and that it processes 'multiple LLM models', but doesn't describe what happens during execution (e.g., sequential/parallel processing, error handling, file naming conventions, or what 'default models' means). For a tool with file I/O and model execution, this leaves significant behavioral gaps unaddressed.
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 appropriately sized (two sentences) and front-loaded with the core purpose. The 'IMPORTANT' note is relevant but could be integrated more smoothly. There's no wasted text, and every sentence adds value (purpose and critical constraint), though the structure is slightly abrupt with the all-caps emphasis.
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 the tool's complexity (file I/O, model execution, batch processing) with no annotations and no output schema, the description is incomplete. It doesn't explain what the output files contain (e.g., raw responses, metadata), how errors are handled, what 'default models' are, or the execution behavior. For a tool with multiple parameters and significant side effects, this leaves too much unspecified for reliable agent use.
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 schema already documents all parameters thoroughly. The description adds minimal value beyond the schema: it reinforces the absolute path requirement (already in schema descriptions) and mentions 'multiple LLM models' (implied by the array parameter). No additional syntax, format, or semantic details are provided beyond what's in the schema descriptions, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send a prompt from a file to multiple LLM models and save responses to files') with specific resources (file input, file output, LLM models). It distinguishes from sibling 'prompt' (which likely takes direct input) and 'prompt_from_file' (which likely doesn't save to files), but doesn't explicitly name these alternatives. The purpose is specific but could be more precise about 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 description implies usage context through the 'IMPORTANT' note about absolute paths, suggesting this tool is for file-based batch processing. However, it doesn't explicitly state when to use this vs. 'prompt_from_file' (which likely processes from file but doesn't save to files) or 'prompt' (direct input). No explicit alternatives or exclusions are provided, leaving usage context somewhat implied rather than clearly defined.
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 provided, the description carries the full burden of behavioral disclosure. It adds value by specifying the absolute path requirement and hinting at default model behavior if 'models_prefixed_by_provider' is not provided. However, it lacks details on error handling, rate limits, authentication needs, or output format, leaving gaps in behavioral transparency for a tool that interacts with LLMs.
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 appropriately sized and front-loaded, with two sentences that directly convey the tool's purpose and a critical requirement. Every sentence earns its place by providing essential information without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (interacting with LLMs), no annotations, and no output schema, the description is incomplete. It covers the basic operation and path requirement but lacks details on output format, error handling, or model behavior, which are important for effective use. This is adequate as a minimum viable description but has clear gaps.
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 schema already documents both parameters thoroughly. The description adds minimal semantic context beyond the schema, such as emphasizing the absolute path requirement and giving examples for model prefixes. This meets the baseline of 3, as the schema does the heavy lifting, but doesn't provide significant additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Send a prompt from a file to multiple LLM models.' It specifies the verb ('send'), resource ('prompt from a file'), and target ('multiple LLM models'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'prompt' or 'prompt_from_file_to_file', which would require a 5.
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 provides some usage guidance by emphasizing the requirement for an absolute file path, but it doesn't explicitly state when to use this tool versus alternatives like 'prompt' (which might accept direct text input) or 'prompt_from_file_to_file' (which might output to a file). The guidance is implied rather than explicit, falling short of the highest scores.
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:

[![just-prompt MCP server](https://glama.ai/mcp/servers/disler/just-prompt/badges/card.svg)](https://glama.ai/mcp/servers/disler/just-prompt)

Score Badge

Copy to your README.md:

[![just-prompt MCP server](https://glama.ai/mcp/servers/disler/just-prompt/badges/score.svg)](https://glama.ai/mcp/servers/disler/just-prompt)

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/disler/just-prompt'

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