FASTMEAN MCP

Overview Schema Source Related Servers Discussions Admin

fastmean_inspect

Read-onlyIdempotent

Read SCM metadata, root parameters, ports, and formulas with paginated sections and detail paths to inspect native data without losing fields or starting calculations.

Instructions

Read SCM metadata, root parameters, ports and formulas without losing fields.

Default summary has compact components and independently budgeted pages; include_objects adds a raw-object page. section selects complete native data with offset/limit pagination. data is a list, mapping or text, as page.kind reports. Use detail_path for nested large fields, e.g. objects [5,"Params"] or analysis ["TD","Expressions"]. Text selections paginate characters. Reuse source_sha256 as expected_source_sha256 on later pages to reject edits between reads. Reads create no jobs and start no calculations or windows.

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": {
      "path": "<path>"
    },
    "name": "fastmean_inspect"
  }
}

Input Schema

Name	Required	Default
`path`	Yes
`limit`	No
`offset`	No
`section`	No	summary
`detail_path`	No
`include_objects`	No
`expected_source_sha256`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.6.0Oct 29, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real value beyond them: 'Reads create no jobs and start no calculations or windows' clarifies the absence of side effects, and the source_sha256 optimistic-concurrency note discloses a stale-read rejection behavior the annotations cannot express. Pagination semantics (character-based for text, independent page budgets) are also disclosed.

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?

Purpose is front-loaded in the first clause and each subsequent sentence covers a distinct parameter behavior with no repetition. It is telegraphic in places ('data is a list, mapping or text, as page.kind reports'), which costs a little readability but not much space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter read tool with an output schema, the description covers selection, pagination, nested traversal and concurrency safety — enough to invoke correctly. Gaps are minor: what 'path' points to and error behavior are not stated, but the output schema covers return shapes.

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 0%, so the description carries the full burden and largely meets it: it explains include_objects, section (complete native data), detail_path with concrete examples ('objects [5,"Params"]', 'analysis ["TD","Expressions"]'), limit/offset, and expected_source_sha256. Only 'path' and the default summary composition remain unexplained.

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?

Opens with a specific verb and resource set: reading SCM metadata, root parameters, ports and formulas, plus the differentiator 'without losing fields'. It is clearly a read/inspect tool distinct from the edit_* and analysis siblings, though it never names a sibling explicitly to route the agent.

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?

Gives intra-tool guidance ('include_objects adds a raw-object page', 'Use detail_path for nested large fields', 'Reuse source_sha256 ... on later pages'), which is genuinely actionable. However it never states when to pick this over fastmean_read_data, fastmean_status or fastmean_preview, so tool selection among siblings is left to inference.

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