Retrieve a single Coordination Connection (CC) by its connection_id (e.g. "CC-06-11-3"). Use when you have the exact identifier; to list or filter CCs, use get_connections. Returns the CC with full evidence on the full tier — or when an endpoint is a sample event — and the base fields only otherwise.
| Name | Required | Description | Default |
|---|---|---|---|
| connection_id | Yes | CC identifier (e.g., "CC-06-11-3") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses conditional return behavior (full evidence on full tier or sample events, otherwise base fields only). However, it does not address side effects, error conditions, or authentication requirements. Given the read-only implication of 'Retrieve', the description adds some context but is not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The purpose is front-loaded, and the alternative routing is included. Every clause earns its place, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with one parameter and no output schema, the description explains the return differentiation (full evidence vs base fields) and directs to the listing alternative. It does not mention error handling or not-found scenarios, but such details are often implicit for retrieval tools. Overall, it is sufficiently complete for the tool’s complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the connection_id parameter already described with an example format. The description repeats the example but does not add additional meaning beyond the schema. This matches the baseline 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a single Coordination Connection by ID, and differentiates it from the sibling get_connections for listing/filtering. The verb 'Retrieve' and resource 'Coordination Connection' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use when the exact identifier is known and directs to get_connections for listing/filtering. This gives clear when-to-use/alternative guidance, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct data slice or operation. For example, `get_actors` retrieves full actor profiles while `query_scp` offers pivoting and comparison; `search_events` finds event IDs and `get_event` retrieves a full record; `get_threads` provides material links separate from `traverse_coordination` for lineage walks. There is no overlap in purpose.
All tool names follow a consistent `verb_noun` pattern with underscore separators. Most use `get_` for retrieval, with `query_scp`, `search_events`, and `traverse_coordination` using different verbs that accurately reflect their distinct actions. The naming is predictable and intuitive.
16 tools is well-scoped for the complexity of an observation platform that covers actors, blocs, events, connections, topology, vocabulary, statistics, and material links. Each tool earns its place by covering a necessary query pattern without unnecessary fragmentation.
The tool set provides comprehensive coverage of the domain: actor retrieval and querying (profiles, comparisons, watch), bloc membership, event discovery and full records, connection traversal and filtering, structural topology, material links, vocabulary lookups, and summary statistics. No obvious gaps in read access are present.
