Marcora

get_ci_finding

Read-onlyIdempotent

Fetch one Context Intelligence finding in full detail by its UUID (from list_ci_findings).

When to use: the user wants the specifics of a finding — the full recommendation, the suggested fix content, or which context items it involves — before deciding to act on it.

The suggested_fix object (when present) contains the proposed replacement content; applying it is done in the Marcora web app (or via update_ci_finding_status to acknowledge/dismiss/resolve without applying).

**Links:** present `link_url` to the user exactly as returned — copy it character for character. Never retype, shorten, or rebuild a link or the IDs inside it.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "finding_id": "<finding_id>"
    },
    "name": "get_ci_finding"
  }
}

Input Schema

Name	Required	Description	Default
`finding_id`	Yes	Required. UUID of the finding (from list_ci_findings).

Output Schema

Name	Required	Description
`id`	No
`status`	No	pending \| acknowledged \| dismissed \| resolved
`summary`	No
`severity`	No
`created_at`	No
`resolved_at`	No
`resolved_by`	No
`finding_type`	No
`process_type`	No
`suggested_fix`	No	Proposed fix: field, new_value, context_item_id.
`recommendation`	No
`context_item_ids`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the description's added value is the note that suggested_fix may be present and that applying it is out of scope for this tool. The link-fidelity instruction ('copy it character for character') is useful operational context, though it is formatting guidance rather than tool behavior.

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?

Front-loaded with the core action, then a labeled 'When to use' block and a bolded Links caveat — easy to scan. The Links paragraph is slightly verbose and reads as an instruction block rather than a tool description, but it is short enough to earn its place.

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?

An output schema exists, so return values need not be enumerated; the description still flags the key field (suggested_fix) an agent must reason about. For a single-parameter read tool with full annotation coverage, nothing needed to call it correctly is missing.

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?

With 100% schema coverage on the single finding_id parameter, the schema already documents it as a required UUID from list_ci_findings. The description's parenthetical '(from list_ci_findings)' largely restates the schema text, so it adds little new meaning beyond the 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?

States a specific verb and resource ('Fetch one Context Intelligence finding in full detail') and immediately scopes it by UUID with the source tool named ('from list_ci_findings'). An agent can distinguish it from list_ci_findings and get_context_item without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

Has an explicit 'When to use' clause listing the concrete triggers (full recommendation, suggested fix content, involved context items) and the decision point ('before deciding to act on it'). It also names the alternatives: applying happens in the Marcora web app, or via update_ci_finding_status for acknowledge/dismiss/resolve.

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

All Marcora 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?