pharo-nc-mcp-server

by mumez

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Most tools have distinct purposes, but there is significant overlap between the two evaluation tools (evaluate_simple_smalltalk and evaluate_smalltalk_with_neo_console) which could cause confusion. The two shutdown tools (quit_neo_console and shutdown_repl_session) also have unclear boundaries, though their descriptions provide some differentiation.
Naming Consistency5/5
All tools follow a consistent verb_noun naming pattern with snake_case throughout. The naming convention is predictable and readable, with clear action-object relationships (e.g., get_class_comment, install_package, shutdown_repl_session).
Tool Count4/5
With 11 tools, the count is reasonable for a Pharo development server. However, there is some redundancy (two evaluation tools, two shutdown tools) that suggests the count could be slightly optimized without losing functionality.
Completeness3/5
The toolset covers core Pharo development operations like class/method inspection, package installation, and system metrics, but has notable gaps. There are no tools for creating or modifying classes/methods, running tests, or managing the Pharo image beyond shutdown operations, which limits workflow coverage.
Average 3.2/5 across 11 of 11 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
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool evaluates expressions and returns results, but lacks critical details: it doesn't specify if this is a read-only or mutating operation, potential side effects, authentication needs, error handling, or rate limits. For a tool that executes code, this omission is significant and could lead to misuse.
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 and front-loaded, with the core purpose stated first, followed by parameter and return value sections. Each sentence adds value, but the structure could be slightly improved by integrating usage context more seamlessly rather than as isolated bullet points.
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 code evaluation tools, lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral risks (e.g., side effects), error cases, or return format details. While it mentions a return, it doesn't describe what the result looks like (e.g., object, string, error message), making it inadequate for safe and effective 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 0%, so the description must compensate. It adds meaning by explaining 'expression' as 'The Smalltalk expression to evaluate' and 'command' as 'The NeoConsole command to use (default: eval)', which clarifies their roles beyond the schema's basic titles. However, it doesn't detail syntax examples, command options beyond 'eval', or constraints, leaving gaps in parameter understanding.
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: 'Evaluate a Pharo Smalltalk expression using NeoConsole.' It specifies the verb ('evaluate'), resource ('Pharo Smalltalk expression'), and mechanism ('using NeoConsole'). However, it doesn't explicitly differentiate from sibling tools like 'evaluate_simple_smalltalk' or 'get_neo_console_command_history', which could provide similar evaluation or console-related functionality.
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 sibling tools like 'evaluate_simple_smalltalk' or explain scenarios where NeoConsole is preferred over other methods. The only implied context is for evaluating Smalltalk expressions, but this is too vague for effective tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves a comment but does not describe behavioral traits like error handling (e.g., what happens if the class doesn't exist), performance considerations, or output format details. This leaves gaps in understanding how the tool behaves beyond basic functionality.
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 and front-loaded, with the main purpose stated first in a clear sentence. The additional sections for 'Args' and 'Returns' are structured efficiently, though they could be more integrated. There is no wasted text, making it concise 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 low complexity (one parameter, no annotations, no output schema), the description is minimally complete. It covers the basic purpose and parameter but lacks details on usage context, error handling, or output specifics. This is adequate for a simple retrieval tool but leaves room for improvement in guiding the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantics beyond the input schema. It explains that 'class_name' is 'The name of the class to get the comment for,' which clarifies the parameter's purpose. However, with 0% schema description coverage and only one parameter, this provides basic context but lacks details like format expectations or examples, resulting in an adequate but not comprehensive explanation.
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: 'Get the comment of a Pharo class.' It specifies the verb ('Get') and resource ('comment of a Pharo class'), making the action and target explicit. However, it does not differentiate from sibling tools like 'get_class_definition' or 'get_method_source', which reduces clarity in distinguishing similar retrieval operations.
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 lacks any mention of prerequisites, context, or exclusions, such as when to choose 'get_class_comment' over 'get_class_definition' or other sibling tools. This absence leaves the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool 'Get[s] a system metric from Pharo using NeoConsole,' implying a read operation, but doesn't specify if it requires authentication, has rate limits, what happens on errors, or the format of the return value beyond 'The metric value.' This is inadequate for a tool with no annotation coverage, leaving key behavioral traits unclear.
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 and front-loaded, with the main purpose stated first, followed by parameter and return details in a structured format. Every sentence earns its place by clarifying the tool's function and usage. However, it could be slightly more concise by integrating the example directly into the parameter explanation.
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 (a tool interacting with a system like Pharo via NeoConsole), no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't explain the return format, error handling, or dependencies, making it insufficient for an agent to use the tool effectively without additional context or trial-and-error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds some meaning beyond the input schema: it explains that the 'metric' parameter is 'The metric to retrieve' and provides examples ('e.g., 'system.status', 'memory.free''). However, with schema description coverage at 0%, the description doesn't fully compensate—it doesn't detail allowed metric names, constraints, or how to discover available metrics. The baseline is 3 because the schema lacks descriptions, and the description adds partial but incomplete param info.
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: 'Get a system metric from Pharo using NeoConsole.' It specifies the verb ('Get'), resource ('system metric'), and context ('from Pharo using NeoConsole'), which distinguishes it from siblings like 'evaluate_smalltalk_with_neo_console' or 'get_method_source'. However, it doesn't explicitly differentiate from all siblings, such as 'get_neo_console_command_history', which might also retrieve data from NeoConsole.
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 lacks any mention of prerequisites, context for selecting this tool over other metric-related or Pharo tools, or exclusions. For example, it doesn't clarify if this is for real-time monitoring, debugging, or how it differs from other data retrieval tools in the sibling list.
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 mentions that the tool shuts down a persistent session and server, implying a destructive action, but fails to detail critical aspects like whether this is reversible, what permissions are required, or potential side effects on other operations. This leaves significant gaps in understanding the tool's behavior.
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 brief and front-loaded, with the core purpose stated in the first sentence and a return value note in the second. There's minimal waste, though the return statement could be slightly more informative. Overall, it's well-structured for quick comprehension.
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 as a shutdown operation with no annotations and no output schema, the description is insufficient. It lacks details on what 'The result of the shutdown operation' entails, such as success/failure indicators or error handling, and doesn't cover behavioral nuances like confirmation prompts or system impacts, making it incomplete for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so the schema fully documents the absence of inputs. The description appropriately adds no parameter information, which is correct and avoids redundancy. A baseline of 4 is assigned as it efficiently handles the zero-parameter case without unnecessary details.
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 ('Shutdown') and the target resource ('persistent NeoConsole REPL session and server'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'quit_neo_console', which might have overlapping functionality, preventing a perfect score.
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 such as 'quit_neo_console' or other shutdown-related operations. It lacks context about prerequisites, timing, or exclusions, leaving the agent to infer usage scenarios independently.
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 of behavioral disclosure. It states the tool retrieves a class definition but does not specify what that includes (e.g., methods, variables, inheritance), whether it requires specific permissions, or how errors are handled (e.g., if the class doesn't exist). This leaves gaps in understanding the tool's behavior beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, using a brief purpose statement followed by clear 'Args' and 'Returns' sections. Every sentence earns its place by directly contributing to understanding the tool's function and parameters without unnecessary details.
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 low complexity (1 parameter, no annotations, no output schema), the description is adequate but incomplete. It covers the basic purpose and parameters but lacks details on behavior, error handling, or output format. Without annotations or output schema, more context on what the 'class definition' includes would improve completeness for effective 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?
The description adds minimal semantics beyond the input schema, which has 0% description coverage. It explains that 'class_name' is 'The name of the class to get the definition for,' clarifying the parameter's purpose. However, it does not provide details like format examples or constraints, so it partially compensates for the schema's lack of descriptions but not fully.
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: 'Get the definition of a Pharo class.' It specifies the verb ('Get') and resource ('definition of a Pharo class'), making it easy to understand what the tool does. However, it does not explicitly differentiate from siblings like 'get_class_comment' or 'get_method_source', which might retrieve related but different information.
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 does not mention sibling tools like 'get_class_comment' (for comments) or 'get_method_source' (for method code), leaving the agent to infer usage based on tool names alone. There are no explicit when/when-not instructions or prerequisites.
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 ('Install') but lacks details on critical behaviors: it doesn't specify if this requires specific permissions, whether it's idempotent, what happens on failure (e.g., error handling), or any side effects like dependencies or system changes. This is a significant gap for a mutation 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 appropriately sized and front-loaded, with the core purpose stated first, followed by clear sections for arguments and returns. Every sentence adds value, though the 'Returns' section could be more specific given the lack of output schema.
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 complexity (a mutation operation with 2 parameters) and the absence of both annotations and an output schema, the description is moderately complete. It covers the purpose and parameters well but falls short on behavioral details and return value specifics, making it adequate but with clear gaps for safe and effective use.
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 description adds substantial meaning beyond the input schema, which has 0% coverage. It explains what each parameter represents (e.g., 'baseline' as the package name, 'repository' as the URL) and provides concrete examples (e.g., 'Historia', 'github://mumez/Historia:main/src'), effectively compensating for the schema's lack of descriptions.
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 with a specific verb ('Install') and resource ('a Pharo package using Metacello'), making it easy to understand what the tool does. However, it doesn't differentiate from sibling tools, which are mostly about evaluation, inspection, or session management rather than package installation, so this distinction is implicit rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 prerequisites (e.g., needing an active Pharo environment), exclusions, or related tools for package management, leaving the agent to infer usage context solely from the purpose.
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 tool evaluates an expression and returns the result, but lacks details on error handling, execution environment, side effects, or performance. For a tool that executes code, this is a significant gap in transparency, as it doesn't cover potential risks 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?
The description is appropriately sized and front-loaded. The first sentence clearly states the purpose, followed by concise sections for 'Args' and 'Returns.' Every sentence adds value without redundancy, making it efficient and well-structured for quick understanding.
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 complexity (executing code with one parameter) and lack of annotations and output schema, the description is minimally complete. It covers the basic purpose and parameter semantics but misses behavioral details like error handling or execution context. It's adequate for a simple tool but has clear gaps in providing a full operational picture.
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 description adds meaningful semantics beyond the input schema. The schema has 0% description coverage, with only a title 'Expression' and type 'string.' The description clarifies that 'expression' is 'The Smalltalk expression to evaluate,' providing context about the parameter's purpose. Since there's only one parameter and the description compensates for the low schema coverage, this earns a high score.
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: 'Evaluate a Pharo Smalltalk expression using the simple -e option.' It specifies the verb ('evaluate') and resource ('Pharo Smalltalk expression'), and distinguishes it from siblings like 'evaluate_smalltalk_with_neo_console' by mentioning the 'simple -e option.' However, it doesn't explicitly contrast with other evaluation methods or siblings, keeping it at a 4.
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 mentions the 'simple -e option' but doesn't explain when this is preferred over other tools like 'evaluate_smalltalk_with_neo_console' or other siblings. There are no explicit when/when-not instructions or prerequisites, resulting in a minimal score.
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 of behavioral disclosure. It states what the tool does but lacks details on permissions, rate limits, error handling, or return format specifics. For a tool with 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with a clear purpose statement followed by brief sections for args and returns. Every sentence earns its place, and there is no redundant or verbose content, 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 low complexity (1 parameter, no output schema, no annotations), the description is adequate but not complete. It explains the purpose and parameter semantics but lacks behavioral details and usage guidelines, which are needed for full contextual understanding in a server with multiple sibling tools.
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 description adds meaning beyond the input schema by explaining that 'class_name' refers to 'The name of the class to get method selectors for'. With schema description coverage at 0%, this compensates well for the single parameter, providing clear semantics without needing to detail syntax or format.
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 ('Get') and resource ('list of method selectors for a Pharo class'), making the purpose understandable. However, it does not explicitly differentiate this tool from sibling tools like 'get_method_source' or 'get_class_definition', which might also involve methods or classes, so it lacks sibling distinction for a perfect score.
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 does not mention when-not scenarios or refer to sibling tools, leaving the agent to infer usage based on the purpose alone, which is insufficient for effective tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the return value but doesn't cover error handling, permissions, rate limits, or whether the operation is read-only or has side effects. For a tool with zero annotation coverage, this leaves significant gaps.
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 and front-loaded, with the core purpose stated first followed by parameter and return details. It avoids unnecessary elaboration, though the structure could be slightly more streamlined.
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, no annotations, and no output schema, the description is partially complete. It covers the purpose and parameters well but lacks behavioral context and output details, making it adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds crucial meaning beyond the input schema, which has 0% coverage. It explains that 'class_name' refers to a Pharo class and 'selector' is the method selector (message name), clarifying the semantics of both parameters effectively.
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 specific action ('Get the source code') and target ('of a specific method in a Pharo class'), distinguishing it from siblings like get_class_definition or get_method_list. It precisely identifies the verb and resource without being tautological.
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 like get_class_definition or get_method_list. The description implies usage for retrieving method source code but lacks explicit context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the return value ('command history as a string, showing numbered entries'), which is helpful. However, it doesn't cover other behavioral aspects such as potential errors (e.g., if no session exists), performance characteristics, or side effects. The description adds some value but lacks comprehensive behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: two sentences that directly state the purpose and return value without unnecessary details. It's front-loaded with the main action. However, it could be slightly more efficient by combining the two sentences, but overall it's highly effective with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is adequate but has gaps. It explains the return value, which is crucial since there's no output schema. However, it doesn't address potential edge cases or errors, and with no annotations, it could benefit from more behavioral context to fully guide an AI agent in a complex environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so the schema fully documents the absence of parameters. The description doesn't need to add parameter information, and it doesn't introduce any confusion. A baseline of 4 is appropriate for tools with no parameters, as there's nothing to compensate for.
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: 'Get the command history from the current NeoConsole session.' It specifies the verb ('Get') and resource ('command history'), and identifies the scope ('current NeoConsole session'). However, it doesn't explicitly differentiate from sibling tools like 'quit_neo_console' or 'shutdown_repl_session' that also interact with NeoConsole sessions, so it doesn't reach the highest score.
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 by specifying 'current NeoConsole session,' suggesting this tool is for retrieving history within an active session. However, it doesn't provide explicit guidance on when to use this tool versus alternatives (e.g., compared to other session-related tools like 'quit_neo_console'), nor does it mention any prerequisites or exclusions, leaving usage somewhat open-ended.
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 full burden. It discloses the action ('Send quit command') and outcome ('terminate the REPL session'), but doesn't mention behavioral aspects like whether this requires specific permissions, if termination is immediate or graceful, or what happens to unsaved state. It adds basic context but lacks richer behavioral details.
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 perfectly concise with two sentences: the first states the action and purpose, the second describes the return value. Every word earns its place with zero redundancy, and key information is front-loaded.
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 0-parameter tool with no annotations and no output schema, the description provides adequate context about what the tool does and what it returns. However, it could be more complete by explaining what 'The result of the quit command' entails (e.g., success confirmation, error message, or session status).
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 0 parameters with 100% schema description coverage, so the baseline is 4. The description doesn't need to explain parameters, and it correctly doesn't mention any. No additional parameter semantics are required or provided.
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 specific action ('Send quit command') and target resource ('to NeoConsole') with the explicit purpose 'to terminate the REPL session'. It distinguishes from siblings like 'shutdown_repl_session' by specifying it's a command sent to NeoConsole rather than a direct session shutdown.
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 context ('to terminate the REPL session') but doesn't explicitly state when to use this versus the sibling 'shutdown_repl_session' tool. It provides clear functional context but lacks explicit comparison or exclusion guidance for alternatives.
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:

[![pharo-nc-mcp-server MCP server](https://glama.ai/mcp/servers/mumez/pharo-nc-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/mumez/pharo-nc-mcp-server)

Score Badge

Copy to your README.md:

[![pharo-nc-mcp-server MCP server](https://glama.ai/mcp/servers/mumez/pharo-nc-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/mumez/pharo-nc-mcp-server)

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/mumez/pharo-nc-mcp-server'

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