place_stats"Hur går det för min förening?": a place in numbers for 7 or 28 days: members, asks, its calendar, its page's reach, efterlysningar, the inbox, and what it lacks (nextSteps: offer one at a time). Numbers only, never who.
| Name | Required | Description | Default |
|---|---|---|---|
| place | No | Its name or id. Left out when they run exactly one. | |
| period | No |
Changes observed during successful MCP inspections.
Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / place / descriptionPrevious value: -"Which place — its name (e.g. \"Poker night\") or its id from list_places. May be left out when the person runs exactly one."New value: +"Its name or id. Left out when they run exactly one."Output schema / (root)Previous value: -{
- "$schema": "http://json-schema.org/draft-07/schema#",
- "additionalProperties": false,
- "properties": {
- "calendar": {
- "additionalProperties": false,
- "properties": {
- "next30Days": {
- "type": "number"
- },
- "past": {
- "type": "number"
- },
- "signedUp": {
- "type": "number"
- },
- "upcoming": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "capacity": {
- "type": [
- "number",
- "null"
- ]
- },
- "going": {
- "type": "number"
- },
- "startsAt": {
- "type": "string"
- },
- "title": {
- "type": "string"
- }
- },
- "required": [
- "title",
- "startsAt",
- "going",
- "capacity"
- ],
- "type": "object"
- },
- "type": "array"
- }
- },
- "required": [
- "past",
- "signedUp",
- "next30Days",
- "upcoming"
- ],
- "type": "object"
- },
- "efterlysningar": {
- "additionalProperties": false,
- "properties": {
- "answers": {
- "type": "number"
- },
- "open": {
- "type": "number"
- }
- },
- "required": [
- "open",
- "answers"
- ],
- "type": "object"
- },
- "face": {
- "additionalProperties": false,
- "properties": {
- "hasCover": {
- "type": "boolean"
- },
- "hasPicture": {
- "type": "boolean"
- },
- "public": {
- "type": "boolean"
- }
- },
- "required": [
- "hasPicture",
- "hasCover",
- "public"
- ],
- "type": "object"
- },
- "inbox": {
- "anyOf": [
- {
- "additionalProperties": false,
- "properties": {
- "threads": {
- "type": "number"
- },
- "unread": {
- "type": "number"
- }
- },
- "required": [
- "threads",
- "unread"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "members": {
- "additionalProperties": false,
- "properties": {
- "admins": {
- "type": "number"
- },
- "asksWaiting": {
- "type": "number"
- },
- "now": {
- "type": "number"
- }
- },
- "required": [
- "now",
- "admins",
- "asksWaiting"
- ],
- "type": "object"
- },
- "name": {
- "type": "string"
- },
- "nextSteps": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "say": {
- "type": "string"
- },
- "step": {
- "type": "string"
- },
- "tool": {
- "type": "string"
- }
- },
- "required": [
- "step",
- "tool",
- "say"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "note": {
- "type": "string"
- },
- "page": {
- "anyOf": [
- {
- "additionalProperties": {},
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "period": {
- "type": "string"
- },
- "place": {
- "type": "string"
- }
- },
- "required": [
- "place",
- "name",
- "period",
- "members",
- "calendar",
- "page",
- "efterlysningar",
- "inbox",
- "face",
- "nextSteps",
- "note"
- ],
- "type": "object"
-}New value: +nullDoes the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is carried by structured data. The description adds two genuinely useful behavioral facts: output is aggregate ('Numbers only, never who') and follow-up suggestions should be surfaced one at a time. It does not describe granularity, caching, or freshness of the counts.
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?
It is a single front-loaded sentence, which is good, but it is a dense run-on mixing Swedish and English terms ('efterlysningar', 'asks', 'nextSteps') that a reader may have to decode. The metric list would be more scannable as discrete items; nothing is strictly wasted, but the packing hurts clarity.
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?
With no output schema, the description usefully enumerates what the numbers cover, which is the key missing piece, and the privacy clause sets expectations about return shape. What is still unspecified is how the payload is structured (single object, per-metric keys) and whether the nextSteps suggestions are part of the response.
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 only 50% and only 'place' is documented in the schema, so the description must carry 'period' – which it does by spelling out 7 or 28 days, matching the enum. The optionality of 'place' when the user runs exactly one place is covered by the schema, not duplicated here, which is appropriate.
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?
States a concrete resource (a place) and a concrete output (numbers over 7 or 28 days) and enumerates the metrics returned: members, asks, calendar, page reach, efterlysningar, inbox, and gaps. That is enough for an agent to know this is an aggregate-stats tool rather than one of the read_* or list_* siblings. It never names a sibling it is not, so differentiation is inferred rather than explicit.
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?
Opens with the exact user trigger ('Hur går det för min förening?'), which gives a clear when-to-use signal, and the two period options are stated inline. It also tells the agent what to do with the result ('nextSteps: offer one at a time'). No when-not-to-use or alternative tool is mentioned, so it falls short of a 5.
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.