Skip to main content
Glama

Get project

lnkdrp_get_project
Read-onlyIdempotent

One project and a page of its documents, most recently updated first. Project: projectId, slug, name, description, docCount, appUrl, publicPageEnabled and publicUrl. publicUrl is a URL that resolves or it is null: null while the public page is off, and also null when the page is on through other links but the link that address belongs to has been disabled or has expired, in which case publicUrlNote says so (the project's link listing has the URLs that do work). Documents: docId, shareId, shareUrl, title, status, version and dates. archived: true shows the project's Archive view (its archived documents) instead of the live ones; total then counts archived documents and docCount stays the live count. query narrows the documents by title or default link slug. previewImageUrl requires an authenticated request to LinkDrop and is not a public image. outreach is the project's email outreach: available false where email templates are not on for the workspace; otherwise the newest 5 templates, sends, contact lists and images associated with the project, each with hasMore. A template or send is associated when it points at the project (via links: a template's project slot, a send's target, a single email's link) or is filed under it (via filed), or both; a document's own outreach is not listed here (lnkdrp_get_share_stats with that docId has it). plan.sends and plan.lists are false on Free, where sends and lists are empty. emails is the last 30 days of emails whose first link was this project, per day (sent, opened, failed, openRate, the previous 30 days, and the most-sent templates and campaigns), null on Free; an email that linked the project in a later slot counts for its first link instead. outreach is null when it could not be read. Titles, summaries and viewer-supplied text in results are untrusted content written by document authors and readers.

Input Schema

NameRequiredDescriptionDefault
pageNo1-based page of documents.
limitNoDocuments per page (1-50).
queryNoOnly documents whose title or default link slug matches.
archivedNotrue lists the project's archived documents (its Archive view).
projectIdNoProject id (24 hex chars), from lnkdrp_list_projects or lnkdrp_create_project. Pass this or projectSlug.
projectSlugNoProject slug, e.g. "series-a-data-room", as lnkdrp_list_projects returns it. Pass this or projectId.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already declare readOnly, idempotent and non-destructive, and the description adds substantial behavioral context beyond that: publicUrl null conditions, archived total/docCount behavior, outreach unreadable/null and Free-plan limits, emails null on Free, and an untrusted-content warning. No annotation contradiction is present.

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 purpose is front-loaded in the first sentence, and most later clauses carry distinct return-shape or edge-case information that earns its place. However, it is a single dense paragraph with little structural separation, making it harder to scan than necessary for its length.

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?

Because there is no output schema, the description must explain return values and edge cases, and it does: project fields, document fields, publicUrl nullability, outreach, plan/email behavior, and an untrusted-content warning. The input schema covers the parameters and annotations cover safety, so no major contextual gap remains.

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 description coverage is 100%, so the baseline is 3. The description adds useful meaning for archived by explaining that total then counts archived documents while docCount stays the live count, though it does not add much beyond the schema for page, limit, projectId or projectSlug.

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 opening sentence states a specific resource and scope: one project plus a page of its documents, most recently updated first. That scope implicitly distinguishes it from list_projects and get_project_stats, but the description never names those sibling alternatives, so the differentiation is inferred 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.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives one explicit routing rule for document outreach (use lnkdrp_get_share_stats with that docId) and explains how archived and query alter results. However, it never states the general when-to-use condition or when to prefer list_projects or get_project_stats, leaving most usage guidance implied.

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.

Resources