Skip to main content
Glama

ppm_ping

Verify MCP server authentication to Odoo and access to PPM models, returning counts of portfolios, programs, projects, and risks.

Instructions

Verify the MCP server can authenticate to Odoo and hit the PPM models.

Returns {ok, uid, portfolios, programs, projects, risks} with counts.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The ppm_ping tool handler function. Authenticates to Odoo and runs search_count on several PPM models (portfolio, program, project, risk, change.request, milestone, status.report), returning a dict with ok/uid/counts.
    @mcp.tool()
    def ppm_ping() -> dict[str, Any]:
        """Verify the MCP server can authenticate to Odoo and hit the PPM models.
    
        Returns {ok, uid, portfolios, programs, projects, risks} with counts.
        """
        c = client()
        uid = c.uid  # triggers authenticate if needed
        counts: dict[str, Any] = {"ok": True, "uid": uid}
        for model in (
            "project.portfolio",
            "project.program",
            "project.project",
            "ppm.risk",
            "ppm.change.request",
            "ppm.milestone",
            "ppm.status.report",
        ):
            try:
                counts[model] = c.execute_kw(model, "search_count", [[]])
            except Exception as e:  # noqa: BLE001
                counts[model] = f"error: {e}"
        return counts
  • The @mcp.tool() decorator registers ppm_ping as a tool on the FastMCP instance.
    @mcp.tool()
  • The client() helper function creates or returns a cached OdooClient instance, used by ppm_ping.
    def client() -> OdooClient:
        global _client
        if _client is None:
            _client = OdooClient.from_env()
        return _client
  • The execute_kw method on OdooClient, used by ppm_ping to call search_count on Odoo models.
    def execute_kw(
        self,
        model: str,
        method: str,
        args: list[Any] | None = None,
        kwargs: dict[str, Any] | None = None,
    ) -> Any:
        return self._call(
            "object",
            "execute_kw",
            [self.db, self.uid, self.secret, model, method, args or [], kwargs or {}],
        )
  • The uid property on OdooClient that triggers authentication, used by ppm_ping to verify connectivity.
    @property
    def uid(self) -> int:
        if self._uid is None:
            self.authenticate()
        return self._uid  # type: ignore[return-value]
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of behavioral disclosure. It does not explicitly state whether this tool is read-only or modifies data, though a ping is assumed safe. Including a statement like 'does not modify any data' would improve 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 extremely concise: two sentences that cover purpose and return value. Every word is necessary and front-loaded.

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?

Given zero parameters and presence of an output schema, the description adequately explains the tool's behavior and return structure. It is complete for a simple health-check tool.

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%. According to guidelines, baseline is 4. No additional parameter information is needed.

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 ('Verify') and clearly identifies the resource (MCP server authentication and PPM model connectivity). It distinguishes itself from sibling tools, which are all action-oriented (e.g., approve, reject), leaving no ambiguity.

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 implicitly defines when to use the tool: to check if the server can authenticate and reach PPM models. Although no explicit when-not or alternatives are given, the tool's nature as a ping makes context clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

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/wethti/qod-ppm-odoo-mcp'

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