Skip to main content
Glama

compute_group_ownership

Read-only

Computes the EFFECTIVE OWNERSHIP (look-through / economic transparency) of a block of the group: "who really owns how much of the sub-subsidiary, going up the whole chain?". Goes up the ownership links and the assignments of people, multiplies the % along each path and sums the paths. ⚠️ ONLY dependencies of type business count as a stake in the capital (structured shares %, or % written in the label): a structural dependency is a HIERARCHY arrow, visual, and stays ignored even if it carries shares — otherwise a containment arrow would make a holder appear that is not one. A stake is therefore modeled with add_dependency({type:'business', shares}). Returns the sorted ultimate holders (people and entities without a holder), their detailed paths, and data-quality notes (links with a % ignored for not being business, unstructured labels, cut cross-holdings, total ≠ 100%). READ-ONLY — it does not modify the schema. Fits whenever an effective %, a transitive ownership, or "who controls X" is asked.

Input Schema

NameRequiredDescriptionDefault
minPctNoFilter: returns only the effective holders above this threshold (in %).
targetCellIdYesID of the block (company/subsidiary) whose effective ownership table is wanted.
expectedProjectIdNoUUID of the project targeted by THIS call. ACTUALLY targets this project instead of the session project. Refused without changing anything if access is not granted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / expectedProjectId / description
      Previous value: -"UUID du projet visé par CET appel. Cible RÉELLEMENT ce projet au lieu du projet de session. Refusé sans rien modifier si l'accès n'est pas accordé."New value: +"UUID of the project targeted by THIS call. ACTUALLY targets this project instead of the session project. Refused without changing anything if access is not granted."
    • changedInput schema / properties / minPct / description
      Previous value: -"Filtre : ne retourne que les détenteurs effectifs au-dessus de ce seuil (en %)."New value: +"Filter: returns only the effective holders above this threshold (in %)."
    • changedInput schema / properties / targetCellId / description
      Previous value: -"ID du bloc (société/filiale) dont on veut la table de détention effective."New value: +"ID of the block (company/subsidiary) whose effective ownership table is wanted."
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, yet the description adds substantial non-obvious behavior: only `business` dependencies count as stakes, `structural` arrows are ignored even if they carry shares, and the exact return contents (sorted ultimate holders, paths, data-quality notes). This is genuine value beyond the annotations.

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 definition is front-loaded with the core meaning and every sentence carries real information (stake semantics, return contents, read-only status). It is somewhat verbose with a rhetorical restatement ('who really owns how much...'), keeping it short of a 5.

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?

No output schema exists, and the description compensates by naming the returned artifacts (ultimate holders, detailed paths, data-quality notes). Combined with the ownership-modeling caveat, an agent has everything needed to call and interpret this tool correctly.

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% and all three parameters (minPct, targetCellId, expectedProjectId) are documented in the schema itself. The description adds no parameter-level meaning beyond what the schema provides, so the baseline of 3 applies.

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?

States a specific verb and resource ('Computes the EFFECTIVE OWNERSHIP ... of a block of the group') and immediately distinguishes it from the sibling compute_direct_ownership by scoping to transitive/look-through ownership up the whole chain. An agent can tell exactly what this tool produces without opening the schema.

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?

Explicitly states when to use it ('Fits whenever an effective %, a transitive ownership, or "who controls X" is asked') and implies the contrast with direct ownership via the up-the-chain framing. It does not name the alternative sibling (compute_direct_ownership) or give an explicit when-not, so it falls short of a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.