Click on "Deploy 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., "@pharo-nc-mcp-server show me the definition of the OrderedCollection class"
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.
A local MCP server to evaluate Pharo Smalltalk expressions and get system information via NeoConsole.
Python 3.10 or later
uv package manager
Pharo with NeoConsole installed
Install Pharo and NeoConsole
Set the PHARO_DIR environment variable to your Pharo installation directory (default: ~/pharo)
Ensure NeoConsole.image is available in the Pharo directory
Related MCP server: navigation-agent-mcp
Clone the repository:
git clone <repository-url>
cd pharo-nc-mcp-serverInstall dependencies using uv:
uv sync --devStart the server:
uv run pharo-nc-mcp-server{
"mcpServers": {
"pharo-nc-mcp-server": {
"command": "uv",
"args": [
"--directory",
"/your-path/to/pharo-nc-mcp-server",
"run",
"pharo-nc-mcp-server"
]
}
}
}evaluate_smalltalk_with_neo_consoleExecute Smalltalk expressions in Pharo using NeoConsole:
# Example usage in MCP client
evaluate_smalltalk_with_neo_console(expression="42 factorial", command="eval")evaluate_simple_smalltalkExecute Smalltalk expressions using Pharo's simple -e option:
# Simple evaluation
evaluate_simple_smalltalk(expression="Time now")get_pharo_metricRetrieve system metrics from Pharo:
# Get system status
get_pharo_metric(metric="system.status")
# Get memory information
get_pharo_metric(metric="memory.free")get_class_commentGet the comment of a Pharo class:
# Get Array class comment
get_class_comment(class_name="Array")get_class_definitionGet the definition of a Pharo class:
# Get Array class definition
get_class_definition(class_name="Array")get_method_listGet the list of method selectors for a Pharo class:
# Get all method selectors for Array class
get_method_list(class_name="Array")get_method_sourceGet the source code of a specific method in a Pharo class:
# Get source code for Array>>asSet method
get_method_source(class_name="Array", selector="asSet")PHARO_DIR: Path to Pharo installation directory (default: ~/pharo)
# Format code
uv run black pharo_nc_mcp_server/
# Lint code
uv run ruff check pharo_nc_mcp_server/
# Run tests
uv run python -m pytest
# Or use the test script
./scripts/test.shThe project includes several convenience scripts in the scripts/ directory:
scripts/format.shFormats all code and documentation files in one command:
Formats Python code using Black
Formats markdown files using mdformat
Runs linting checks with Ruff
./scripts/format.shscripts/test.shRuns the test suite using pytest:
./scripts/test.shEvaluate a Pharo Smalltalk expression using the simple -e option.
Args:
expression: The Smalltalk expression to evaluate
Returns:
The result of the evaluation
| Name | Required | Description | Default |
|---|---|---|---|
| expression | Yes |
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.
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.
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.
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.
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.
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.
Evaluate a Pharo Smalltalk expression using NeoConsole.
Args:
expression: The Smalltalk expression to evaluate
command: The NeoConsole command to use (default: eval)
Returns:
The result of the evaluation
| Name | Required | Description | Default |
|---|---|---|---|
| expression | Yes | ||
| command | No | eval |
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.
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.
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.
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.
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.
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.
Get the comment of a Pharo class.
Args:
class_name: The name of the class to get the comment for
Returns:
The class comment
| Name | Required | Description | Default |
|---|---|---|---|
| class_name | Yes |
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.
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.
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.
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.
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.
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.
Get the definition of a Pharo class.
Args:
class_name: The name of the class to get the definition for
Returns:
The class definition
| Name | Required | Description | Default |
|---|---|---|---|
| class_name | Yes |
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.
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.
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.
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.
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.
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.
Get the list of method selectors for a Pharo class.
Args:
class_name: The name of the class to get method selectors for
Returns:
The list of method selectors
| Name | Required | Description | Default |
|---|---|---|---|
| class_name | Yes |
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.
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.
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.
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.
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.
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.
Get the source code of a specific method in a Pharo class.
Args:
class_name: The name of the class
selector: The method selector (message name)
Returns:
The method source code
| Name | Required | Description | Default |
|---|---|---|---|
| class_name | Yes | ||
| selector | Yes |
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.
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.
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.
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.
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.
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.
Get the command history from the current NeoConsole session.
Returns:
The command history as a string, showing numbered entries of previously executed commands
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Get a system metric from Pharo using NeoConsole.
Args:
metric: The metric to retrieve (e.g., 'system.status', 'memory.free')
Returns:
The metric value
| Name | Required | Description | Default |
|---|---|---|---|
| metric | Yes |
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.
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.
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.
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.
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.
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.
Install a Pharo package using Metacello.
Args:
baseline: The baseline name of the package (e.g., 'Historia')
repository: The repository URL (e.g., 'github://mumez/Historia:main/src')
Returns:
The result of the package installation
| Name | Required | Description | Default |
|---|---|---|---|
| baseline | Yes | ||
| repository | Yes |
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.
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.
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.
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.
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.
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.
Send quit command to NeoConsole to terminate the REPL session.
Returns:
The result of the quit command
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Shutdown the persistent NeoConsole REPL session and server.
Returns:
The result of the shutdown operation
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0evaluate_simple_smalltalkevaluate_smalltalk_with_neo_consoleget_class_commentget_class_definitionget_method_listget_method_sourceget_neo_console_command_historyget_pharo_metricinstall_packagequit_neo_consoleshutdown_repl_sessionScored across 11 tools
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.
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).
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.
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.
Repository knowledge graph MCP server for codebase understanding and debugging.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Self-hosted MCP server: 26 deterministic dev, security, and EVM tools.
