Skip to main content
Glama
Sign In

Meta Council

by com.meta-council
OverviewDiscussionsAdmin

Get Consulting Engagement

get_consulting_engagement
Read-onlyIdempotent

Get one owned engagement with its document revisions, milestones, and internal deliverables. Long document bodies are previewed.

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": {
      "engagement_id": "<engagement_id>"
    },
    "name": "get_consulting_engagement"
  }
}

Input Schema

NameRequiredDescriptionDefault
engagement_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": false,
-  "properties": {
-    "text": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "text"
-  ],
-  "type": "object"
-}New value: +null
  2. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is already known. The description adds meaningful behavior beyond that by specifying the included related entities and the truncation behavior for long document bodies. No contradiction with annotations was found.

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

Conciseness5/5

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

The description is one focused sentence that front-loads the core action and result summary, followed by a useful behavioral detail. There is no filler or repetition of annotation information.

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 simple read-by-ID tool with one required UUID parameter, no output schema, and safety annotations already provided, the description covers the important retrieval scope and preview behavior. It could mention error cases like missing or inaccessible engagements, but the tools is simple enough that the current description is reasonably complete.

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?

The schema has no descriptive text and 0% description coverage, but the single parameter is self-explanatory through its name and uuid type. The description adds the 'owned' scoping nuance, which gives some context about which engagements are accessible. Still, it does not directly explain the parameter's role or any lookup behavior.

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 description names a specific verb ('Get'), a specific resource ('one owned engagement'), and the exact related data that will be returned ('document revisions, milestones, and internal deliverables'). This clearly distinguishes it from list-oriented tools like list_consulting_engagements and from consulting mutation tools like update_consulting_engagement.

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?

The description makes the primary use case clear: retrieve a single owned engagement by ID, including its related objects. It does not explicitly name alternatives or state when not to use this tool, such as pointing to list_consulting_engagements for listing. The usage context is implied rather than stated.

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

All Meta Council 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