Skip to main content
Glama

apis-io

by io.apis
OverviewDiscussionsAdmin

get_cohort

Read-only

One cohort: its identity, its population, and the full member roster with each provider's Kin Score and agent readiness. Understanding plan. The analysis parts (stats/rankings/scores/capabilities) are Understanding too — they moved down from Influence on 2026-09-01. Priced per result — $0.005 per request plus $0.0002 per record returned (less past 100), capped at $0.50 a request, under pay-as-you-go; included in Understanding and Influence. Estimate first at /api/v1/prices/estimate. See apis://prices.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindYes
slugYes
contextNoOptional: why you are asking. One sentence — the task you are trying to complete, or what you expect to get back. Never included in the answer and never used to rank; it is read only when a result turns out to be wrong, which is when knowing the intent is what makes the report actionable.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / context
      Added value: +{
+  "description": "Optional: why you are asking. One sentence — the task you are trying to complete, or what you expect to get back. Never included in the answer and never used to rank; it is read only when a result turns out to be wrong, which is when knowing the intent is what makes the report actionable.",
+  "type": "string"
+}
  2. Added

TDQS

B3.4/5.0
Behavior3/5

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

Annotations declare readOnlyHint=true, so the description does not need to emphasize read-only. It adds important context: the analysis parts moved from Influence to Understanding on a date, and pricing details are included. However, it does not disclose any side effects or limitations beyond pricing, but for a read-only tool with annotations, this is adequate.

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?

The description is front-loaded with the resource and key data returned, then adds plan and pricing info. It is a bit long but every sentence carries information (pricing, plan, date of change). No fluff, but it could be more concise by moving pricing to a separate note.

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?

Given the complexity of a cohort with roster and scores, the description covers the returned data adequately but does not mention pagination or result limits (only pricing limits). No output schema so the description must carry the burden, and it does for the main contents but not for edge cases like missing cohort or error handling.

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?

Schema description coverage is 33% (only the 'context' parameter has a description), and the description does not explain 'kind' or 'slug'. The description does imply that 'slug' identifies the cohort and 'kind' might be the type, but it is not explicit. Since coverage is low, the description should compensate but does not fully, so a 3 is appropriate.

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 it returns a cohort with identity, population, and member roster including Kin Score and agent readiness, but does not explicitly say it is a read operation or that it is the singular version of the more granular sibling tools. It distinguishes from siblings by naming the included analysis parts, but could be clearer about what the tool is NOT (e.g., not rankings/stats alone).

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?

No explicit when-to-use vs alternatives, but the description implies this is for getting a single cohort overview. It does not mention alternatives like find_cohorts or compare_cohorts, so an agent might not know when to pick this over those. Lack of exclusions or alternative routing is a gap.

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

All apis-io toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources