OrgLines

CRM: Get pipeline

crm_pipeline_get

Read-only

Read the workspace's lead pipelines: the built-in status-based «Вхідні заявки» (slug 'inbound') and the workspace's own ones (e.g. 'cold_outreach' «Пошук клієнтів»). Each stage: slug, name_uk, category (sourcing, enrichment, channel_check, proposal, approval, outreach, follow_up, reply, terminal), order, color, is_terminal, lead_status (the Lead.status it derives), requires_approval, can_set and the number of leads on it; plus transitions and goal_per_month. can_set=false means you can only PROPOSE that stage — a person with the approval right confirms. Read-only. Pass 'pipeline' for one.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "crm_pipeline_get"
  }
}

Input Schema

Name	Required	Description	Default
`counts`	No
`pipeline`	No
`include_archived`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

B3.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint/openWorldHint/destructiveHint, but the description adds a genuinely non-obvious behavioral rule: can_set=false means the agent may only PROPOSE a stage and a human with approval rights confirms. It also documents the approval and terminal semantics of stages. It could go further on invalid-slug or archived handling.

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 opening clause, but the middle is a dense run-on enumeration of stage fields and categories that is hard to scan. The field list is defensible given there is no output schema, but the prose is not structured for quick parsing.

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?

With no output schema, the detailed field and category enumeration usefully describes the return shape, and the proposal/approval rule covers key behavior. However, two of three input parameters remain unexplained and there is no note on what happens for an unknown or missing pipeline.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the parameter burden, yet it only covers 'pipeline' (accepting slugs like 'inbound' or 'cold_outreach'). The 'counts' and 'include_archived' booleans are never explained, leaving two of three parameters ambiguous.

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?

States a specific verb and resource ('Read the workspace's lead pipelines') and precisely enumerates what each stage record contains, so an agent knows exactly what it gets back. It does not explicitly distinguish itself from the sibling crm_pipeline_define (create/modify pipelines), which keeps it from a 5.

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?

'Read-only. Pass 'pipeline' for one.' tells the agent it can list all pipelines or narrow to a single one by slug, which is real usage guidance. There are no when-to-use vs. when-not conditions and no alternative tool is named for pipeline editing, so guidance is implied rather than explicit.

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

All OrgLines tools Inspect

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

Need Help?