Mencoro

Get an organization

get_organization

Read-onlyIdempotent

An organization's profile, its status, the caller's own role in it, and how many active members and pending invitations it has, and how many of its projects the caller can access. Use list_projects first to find the organizationId.

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": {
      "organizationId": "<organizationId>"
    },
    "name": "get_organization"
  }
}

Input Schema

Name	Required	Description	Default
`organizationId`	Yes

Output Schema

Name	Required	Description	Default
`stats`	Yes
`organization`	Yes	An organization the caller is a member of

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 29, 2026
- addedOutput schema / properties / stats / properties / invitations / properties / pending / description
```
Added value: +"Pending invitations. Null for a member restricted to selected projects."
```
- changedOutput schema / properties / stats / properties / invitations / properties / pending / type
```
Previous value: -"integer"New value: +[
+  "integer",
+  "null"
+]
```
- changedOutput schema / properties / stats / properties / members / properties / total / description
```
Previous value: -"Active members"New value: +"Active members. Null for a member restricted to selected projects."
```
- changedOutput schema / properties / stats / properties / members / properties / total / type
```
Previous value: -"integer"New value: +[
+  "integer",
+  "null"
+]
```
AddedSep 28, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered. The description adds real behavioral context by disclosing that results are scoped to the caller (own role, count of projects the caller can access), implying permission-dependent output. It does not mention error behavior when the organizationId is invalid or the caller lacks access.

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?

Two sentences, front-loaded with the resource and its contents, with the ID-sourcing tip last. The first sentence is a long run-on chain of 'and' clauses that could be tightened, but nothing is wasted.

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?

With an output schema present, most of the description's text redundantly re-lists return fields rather than covering what the schema cannot. It omits sibling differentiation and any failure modes, which matter given there is both get_organization and get_organization_overview in the tool set.

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% and the single required organizationId has no schema description, so the description must compensate — and it does, by telling the agent to obtain the ID from list_projects. That is a meaningful addition beyond the schema, though it doesn't state the ID format or where else to find it.

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?

The description names the specific resource and enumerates what is returned (profile, status, caller's role, member/invitation counts, accessible project count), which pins down the scope well. However, it is a bare noun phrase with no verb, and it does not distinguish itself from near-siblings like get_organization_overview or get_project.

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?

It gives one concrete prerequisite-style hint ('Use list_projects first to find the organizationId'), which is genuinely useful for obtaining the required ID. It says nothing, though, about when to pick this over get_organization_overview or the list_* tools, so usage is only implied.

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

All Mencoro 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.