pypddlengine

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct aspect of PDDL exploration: initialization, action querying, execution, state inspection, goal checking, history, and domain/problem retrieval. There is no overlap or ambiguity.
Naming Consistency5/5
All tools follow a consistent 'pddl_<verb>_<object>' pattern (e.g., pddl_init, pddl_get_available_actions, pddl_execute_action). The naming is uniform and predictable.
Tool Count5/5
With 10 tools, the server is well-scoped. Each tool provides a necessary function for exploring PDDL problems without superfluous or missing functionality.
Completeness5/5
The tool set covers the full lifecycle of a PDDL exploration session: initialization, action enumeration, execution, state queries, goal detection, reset, history, and retrieval of domain/problem definitions. No obvious gaps remain.
Average 3.7/5 across 10 of 10 tools scored. Lowest: 3.1/5.
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 Apache 2.0.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals what is returned (success status, new state summary, goal reached), which gives some insight into behavior. However, it does not explicitly state that the action mutates the internal state or what the side effects are. For a tool with no annotations, more disclosure on state changes would be expected.
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, concise sentence that front-loads the core action and mentions return values. It is not verbose, but could be improved by adding structured details like prerequisites or error behavior without significantly increasing length.
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 mutates state and is part of a workflow (with 9 sibling tools), the description lacks critical context: what constitutes a valid action, how to handle errors, what format the return values take, and that the state changes after execution. With no output schema, more descriptive completeness is needed.
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?
Both parameters (action_name, args) have descriptions in the schema with 100% coverage. The tool description adds no additional meaning beyond what the schema already provides. Baseline score is appropriate given parameter descriptions in the schema.
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 'Execute' and the resource 'a PDDL action with given arguments', making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools like pddl_init or pddl_get_current_state, which cover other aspects of the PDDL workflow.
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 or when not to use this tool, nor does it mention prerequisites (e.g., that the PDDL domain must be initialized first) or alternative tools for other tasks. The agent is left to infer context from 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 only states the action but does not explicitly confirm it is read-only, mention side effects, or specify preconditions like initialization. This is insufficient for an agent to understand the tool's safety and dependencies.
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 very concise at six words, with no wasted text. It is front-loaded with the key action. However, it could benefit from a slight expansion (e.g., on return value) without sacrificing conciseness, so it is not a perfect 5.
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?
The description is incomplete: it does not specify the return type (implied boolean but not stated), nor does it mention behavior when no goal is defined or when planning is not initialized. Given zero parameters and no output schema, the description should clarify these aspects to be fully useful.
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 input schema has zero parameters and schema description coverage is 100%, so no parameter information is needed. The description adds no extra value for parameters, but the baseline of 3 is appropriate given the high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: checking if the goal state has been reached. It uses a specific verb ('Check') and a specific resource ('goal state'), and it distinguishes itself from sibling tools like pddl_get_current_state or pddl_execute_action, which have different purposes.
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 checking the current state manually or after executing actions. There are many sibling tools, but no exclusions or context about prerequisites (e.g., being initialized) are mentioned.
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 full burden. It only states it returns the state with predicates and fluents, but omits behavioral traits such as idempotency, side effects, cost, or performance implications. For a read operation, transparency is minimal.
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?
A single, front-loaded sentence of 10 words. No wasted words; every part adds value. It is appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description explains what it returns (current state with predicates and fluents). However, it does not specify the format of the state (e.g., PDDL string, JSON object) or any additional context like the scope of 'current' state. It is minimally adequate but not fully complete.
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?
There are zero parameters and schema coverage is 100% (vacuously). The description adds meaning by specifying what the state contains ('all true predicates and fluents'), which goes beyond the empty schema. Baseline is 4 for zero parameters, and this is met.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('current state') and adds detail about contents ('all true predicates and fluents'). It clearly distinguishes from sibling tools like pddl_get_available_actions or pddl_get_action_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description only states what it does, without any context about prerequisites, exclusions, or when to prefer other tools like pddl_get_domain or pddl_get_problem.
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 must carry the full burden. It states a pure read operation ('Get the history'), which is accurate for a non-destructive tool. However, it does not specify what the history contains (e.g., timestamps, action names, results) or whether it resets with the session. This is adequate but minimal.
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 sentence with no wasted words. It is front-loaded with the key action and resource, making it easy to scan.
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 has no parameters and no output schema, the description is reasonably complete for a simple retrieval operation. However, it could be more helpful by hinting at what the output format looks like (e.g., list of action names) or noting that the history persists across tool calls but resets on session reset. Without output schema, this is a minor gap.
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 schema has no parameters and 100% description coverage, so the baseline is 3. The description adds value by clarifying that the history is for the entire session, which is not implied by the schema. This is a slight improvement over the baseline.
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 the resource 'history of all actions taken so far in this session', which distinguishes it from siblings like pddl_get_available_actions or pddl_get_current_state. It is specific and unambiguous.
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 indicates when to use this tool (to retrieve action history in the current session) but does not provide exclusions or alternatives. Given the sibling tools, it could benefit from mentioning that this tool is for post-action review, not for available actions or state.
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. The description only states what the tool returns and its usefulness. It does not disclose whether the operation is read-only, what format the problem string is in, error conditions (e.g., if session not initialized), or any side effects. For a retrieval tool, these are 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise two-sentence structure. The first sentence front-loads the core purpose ('Get the PDDL problem string...'), and the second sentence adds utility without waste. Every word earns its place.
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 simplicity of the tool (no parameters, no output schema, no annotations), the description should still cover prerequisites (e.g., session must be initialized), format of the return value, and whether it's read-only. The description only mentions the problem string and its usefulness, leaving significant gaps in understanding for an agent. It is incomplete for a planning-related tool.
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 input schema has no parameters, and schema description coverage is 100% (trivially). The description adds no parameter-specific information because there are none. Baseline 3 is appropriate since the schema already covers the parameter space fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the PDDL problem string used to initialize the session, with a specific verb ('Get') and resource ('PDDL problem string'). It distinguishes from sibling tools like pddl_get_domain (which gets the domain) and pddl_get_current_state (which gets the current state) by highlighting that it re-reads objects, initial state, and goal conditions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Useful for re-reading objects, initial state, and goal conditions.' This gives contextual guidance on when to invoke the tool. However, it does not explicitly state when not to use it or name alternatives, though the context of sibling tools makes the intended usage reasonably clear.
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 must fully disclose behavioral traits. It states the tool returns action names and arguments from the current state, suggesting a read-only query. However, it does not explicitly state that the tool is side-effect-free, idempotent, or non-destructive. For a planning tool, this omission could lead an agent to assume mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and contains zero filler. Every word adds value: it states the action and the output in a front-loaded, scannable structure. Perfectly concise for a simple query tool.
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 there is no output schema, the description should adequately explain the return value. It states 'action names and arguments' but does not specify format (e.g., list of strings, objects with fields) or behavior in edge cases (e.g., empty state, invalid state). For a tool in a planning domain, the description is minimally complete but leaves room for ambiguity.
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, so the description correctly implies no input is needed. The parameter coverage is 100% vacuously, and the description adds value by confirming that no arguments are required. A higher score would require additional context about default behavior, but for zero parameters this is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly identifies the resource ('all actions that can be executed in the current state'). It distinguishes itself from sibling tools like pddl_execute_action (which executes) and pddl_get_current_state (which returns the state), making the purpose unambiguous.
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 in a planning context (getting possible actions before execution) but lacks explicit guidance on when to use versus alternatives. No mention of when not to use this tool or prerequisites like needing an initialized PDDL state. The guidance is only implicit.
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 must cover behavioral aspects. The description implies this is a read-only, non-destructive operation, but does not explicitly guarantee safe behavior or mention any side effects, rate limits, or prerequisites.
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 extremely concise with only two short sentences. Every word adds value: the verb 'Get', the resource 'PDDL domain string', the purpose 'used to initialize this session', and the use case 're-reading'. No redundancy.
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?
Given the tool has no parameters, no output schema, and zero annotations, the description covers the core purpose and usage well. It explains what the domain is used for and what you can do with it, which is sufficient for a simple retrieval tool. It could mention that it returns the current domain (not a past one), but the completeness is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the baseline is 4. The description adds value by explaining the semantics of the return value (PDDL domain string, contains action schemas, predicates, types) which goes beyond the empty schema.
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 'Get the PDDL domain string', which is a specific verb+resource. It also mentions purpose: 'to initialize this session' and lists what can be re-read (action schemas, predicates, types), which helps distinguish it from sibling tools like pddl_get_problem.
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 use case: re-reading the domain after initialization. It says 'useful for re-reading action schemas, predicates, and types', which gives context but does not explicitly state when not to use it or mention alternatives from siblings.
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 bears the full burden of behavioral disclosure. It only states that initialization must happen first but does not disclose what the tool does internally (e.g., whether it clears previous state, if it validates the domain/problem, or what side effects occur). For a setup tool, the agent needs to know session lifecycle 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 consists of two short, direct sentences. The first states the action and inputs; the second gives critical ordering guidance. There is no redundant or extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must explain what happens after initialization. It does not mention return values (e.g., success confirmation, session ID, or error messages). For a simple init tool, this is adequate but leaves the agent uninformed about the result of the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description merely restates 'domain and problem' without adding any additional semantics (e.g., format expectations, size limits, or hints about PDDL syntax). It adds no value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Initialize' and identifies the resource as a 'PDDL exploration session'. It lists the required inputs (domain and problem) and implicitly distinguishes from the sibling tool 'pddl_init_from_files', which appears to be an alternative initialization method. This is a precise and clear purpose statement.
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 explicitly states 'Must be called first before using other tools', providing clear usage order. However, it does not explain when to prefer this tool over 'pddl_init_from_files' or describe any prerequisites or conditions for calling it. This is a clear context but lacks exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses that the tool initializes a session and reads files, which implies no destructive side effects. However, it does not mention what happens if files are invalid or missing, or whether it resets any existing session state. Still, the core behavior is well described and not contradictory.
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, compact sentence that front-loads the action and purpose, followed immediately by usage guidance. No wasted words—every part earns its place.
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?
Given two simple string parameters (paths) and no output or nested objects, the description covers the essential: what the tool does, when to use it, and how it differs from the sibling. It does not explain the return value, but since there is no output schema, this is an acceptable omission for a session-initialization tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, meaning both parameters have descriptions in the schema itself. The description adds no additional details beyond what the schema provides (the meaning of domain_path and problem_path is self-explanatory from their names and descriptions). With full schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Initialize' and the resource 'PDDL exploration session'. It also specifies the mechanism ('by reading domain and problem from files'), which precisely distinguishes this tool from its sibling pddl_init.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool ('when the PDDL definitions are available as files') and when not to ('instead of pddl_init'). It also provides a clear rationale ('to avoid duplicating large strings in the conversation'), making the decision easy for the AI.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states that the tool resets state and clears history, which are key behavioral traits. No additional details (e.g., permissions, reversibility) are given, but the description is sufficient for a simple reset operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action. Every word earns its place. No redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema. The description fully covers what it does and why to use it. It is contextually complete for a reset operation in a planning domain.
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?
There are no parameters, so schema coverage is 100%. The baseline is 4 for zero-parameter tools. The description adds no parameter info, which is acceptable since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resets to the initial state and clears action history, distinguishing it from sibling tools like pddl_execute_action or pddl_get_current_state. The verb 'Reset' plus resource 'initial state' and 'action history' is specific and unambiguous.
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 includes 'Use this to try a different approach,' which provides clear context for when to use the tool. However, it does not explicitly mention when not to use it or compare it to alternatives like pddl_init, so a minor gap exists.
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:

[![pypddlengine MCP server](https://glama.ai/mcp/servers/AIT-Complex-Dynamical-Systems/pypddlengine/badges/card.svg)](https://glama.ai/mcp/servers/AIT-Complex-Dynamical-Systems/pypddlengine)

Score Badge

Copy to your README.md:

[![pypddlengine MCP server](https://glama.ai/mcp/servers/AIT-Complex-Dynamical-Systems/pypddlengine/badges/score.svg)](https://glama.ai/mcp/servers/AIT-Complex-Dynamical-Systems/pypddlengine)

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/AIT-Complex-Dynamical-Systems/pypddlengine'

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