Skip to main content
Glama
Sign In

OrgGen AI

by ai.orggen
OverviewDiscussionsAdmin

get_linked_project

Read-only

Reads the project linked to a block of THIS project, THROUGH the link — a PREVIEW (title, counts, block skeleton: id, name, type, parent, desc, and the link each block itself carries), not the detailed content. With depth, DESCENDS the chain over several levels and returns a nested array — enough to build a destination table over an entire tree WITHOUT switching from project to project. With includeBlockTitles, attaches to each block the inventory of its content blocks (id, type, TITLE — without the entries): this is what lets you decide to ADD a block or MERGE with an existing block. The read honors what each link grants and NOTHING more, and access is RE-RESOLVED at EACH level (a right on a project does not open what it links): PINNED version if the link carries one, SCOPE if access comes from a shared block (access.boundedToCell then says so explicitly). Requires READ access to the target project — a project role, even plain viewer, or a block share; otherwise the call refuses and says why, and a refused level does not interrupt the others. An API key BOUNDED to projects does not reach a project excluded from its scope either: it is OMITTED and the refusal is named (out_of_key_scope) rather than returned empty. ⚠️ truncated says whether this project links projects that THIS call did NOT read, and why (requestedDepth: a deeper request is needed · depthCeiling: ceiling reached, open the project directly · projectBudget: aim at a more precise branch) — null means everything that hangs below is in the response. ⚠️ notIncluded lists what the preview does NOT carry: its silence does not prove that the target project has none. To WRITE into this project (if you have access to it): writing into it requires TARGETING it — over MCP, expectedProjectId on each write or set_active_project; in the in-app chat neither exists: nothing is written there this turn, the interface (or focus_view dive, run at turn end) dives in, and the writing happens on the NEXT turn.

Input Schema

NameRequiredDescriptionDefault
depthNoHow many link LEVELS to descend. 1 (default): only the project linked to this block. 2 and more: the projects that THAT one links, and so on — the response then gains a `nested` array, one element per level, each with its own access resolution. Useful to build a destination table over a tree WITHOUT switching from project to project. Ceiling 4; at most 12 projects read per call, the head target included in the budget. Any branch left aside is DECLARED (`truncated`) rather than silent.
cellIdYesID of the block of THIS project that carries the link to read. The read goes THROUGH the link: it honors its possible PINNED version and its scope, and never gives more than this link grants.
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.
includeBlockTitlesNoAttach to each block the inventory of its content blocks — id, type and TITLE, without the entries or the text. This is what lets you decide to ADD a block or MERGE with an existing block without carrying its content. FALSE by default. Applies to ALL levels, not only the first.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / cellId / description
      Previous value: -"ID du bloc de CE projet qui porte le rattachement à lire. La lecture passe PAR le rattachement : elle honore son éventuelle version FIGÉE et son périmètre, et ne donne jamais plus que ce que ce lien accorde."New value: +"ID of the block of THIS project that carries the link to read. The read goes THROUGH the link: it honors its possible PINNED version and its scope, and never gives more than this link grants."
    • changedInput schema / properties / depth / description
      Previous value: -"Combien de CRANS de rattachement descendre. 1 (défaut) : le seul projet rattaché à ce bloc. 2 et plus : les projets que CELUI-LÀ rattache, et ainsi de suite — la réponse gagne alors un tableau `nested`, un élément par cran, chacun avec sa propre résolution d'accès. Utile pour construire une table de destination sur une arborescence SANS basculer de projet en projet. Plafond 4 ; au plus 12 projets lus par appel, budget compris la cible de tête. Toute branche laissée de côté est DÉCLARÉE (`truncated`), jamais tue."New value: +"How many link LEVELS to descend. 1 (default): only the project linked to this block. 2 and more: the projects that THAT one links, and so on — the response then gains a `nested` array, one element per level, each with its own access resolution. Useful to build a destination table over a tree WITHOUT switching from project to project. Ceiling 4; at most 12 projects read per call, the head target included in the budget. Any branch left aside is DECLARED (`truncated`) rather than silent."
    • 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 / includeBlockTitles / description
      Previous value: -"Joindre à chaque bloc son inventaire de blocs de contenu — id, type et TITRE, jamais les entrées ni le texte. C’est ce qui permet de décider AJOUTER un bloc ou FUSIONNER avec un bloc existant sans transporter son contenu. FAUX par défaut. S’applique à TOUS les crans, pas seulement au premier."New value: +"Attach to each block the inventory of its content blocks — id, type and TITLE, without the entries or the text. This is what lets you decide to ADD a block or MERGE with an existing block without carrying its content. FALSE by default. Applies to ALL levels, not only the first."
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Far exceeds the readOnlyHint/openWorldHint annotations: access is re-resolved at each level, pinned versions and block-share scope are honored, refusals are named per level without aborting others, key-scoped projects are omitted as out_of_key_scope rather than returned empty, and truncated/notIncluded explain what is missing and why. It even discloses the write-targeting requirement (expectedProjectId vs set_active_project) that governs follow-up mutations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in the first sentence, but the body is very long and heavily formatted with bold, caps and warning emojis, and the closing paragraph about writing into the target project is tangential to a read tool. The density costs readability despite containing little outright waste.

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?

There is no output schema, and the description carries that burden well: it enumerates the preview fields, explains the nested array for multi-level descent, and defines truncated and notIncluded including what their silence does and does not prove. An agent has everything needed to call and interpret this 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?

Schema coverage is 100%, so the schema already documents all four parameters; the baseline would be 3. The description adds conceptual meaning the schema does not fully carry — why depth yields a nested array with per-level access resolution, and how expectedProjectId interacts with key scope and refusal semantics — so it earns slightly above baseline.

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 first sentence names a specific verb (Reads), a precise resource (the project linked to a block of THIS project, through the link) and an explicit scope boundary (a PREVIEW, not the detailed content). This cleanly separates it from siblings like get_full_data, get_cell_details, get_active_project and fork_linked_project.

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?

Gives clear conditions for the optional behavior: depth to build a destination table over a tree 'WITHOUT switching from project to project', and includeBlockTitles to decide whether to ADD or MERGE a block. It stops short of naming the alternative tools an agent should pick instead when it wants full content, so no explicit exclusions or alternatives are stated.

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

All OrgGen AI toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources