Universe MCP by usefulapi

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

Annotations already declare readOnlyHint=true, so 'Read-only' restates structured data rather than adding context. The description does clarify that both endpoint dates are inclusive and that results are bucketed by day, which is genuinely useful, but says nothing about openWorldHint implications, rate limits, or what an event with no sales returns.

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 short sentences, front-loaded with the outcome and grain, no filler. The trailing 'Read-only.' is redundant with annotations and earns little, which keeps it just below a 5.

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?

There is no output schema, so the description carries the burden of explaining the result shape. 'Ticket sales per day' hints at day-bucketed rows but never says what fields come back (date, count, revenue) or whether empty days are included — a meaningful gap for an analytics tool.

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 all three params documented, so the schema does the heavy lifting. The description only reinforces the YYYY-MM-DD format and makes the inclusive boundary explicit — baseline 3 is right for this level of added meaning.

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 specific verb and resource with an explicit grain ('ticket sales per day for an event') plus the range shape. That aggregation grain already separates it from the get/list siblings, though it never names an alternative explicitly.

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?

Usage is only implied: it's clearly the analytics rollup over an event's sales while universe_list_orders/universe_get_order would supply raw records, but the description never says so or states when-not to use it. Inclusive-boundary semantics is the only real guidance offered.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the closing 'Read-only' only echoes structured data. The valuable addition is the field list (description, address, dates, capacity, tickets sold, sales amount, category, host), which sets expectations for the response in the absence of an output schema. It does not mention what happens for a missing id, which keeps it from a 5.

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 and a fragment, with the operation and the returned fields front-loaded. The sibling pointer is appended where it belongs, and nothing is repetitive or filler.

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 returned-field enumeration is the key thing an agent needs and it is present. Error behavior for an invalid or missing id and the distinction from universe_list_events are the remaining omissions, minor for a simple getter.

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?

There is a single required parameter, and the schema documents it (eventId, 100% coverage). The description adds only the 'by id' framing, no format, source, or retrieval guidance beyond the schema. Baseline 3 for a fully documented single parameter.

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 specific verb and resource ('Fetch one event by id') and then enumerates the returned fields. It also names the sibling that handles a different resource (universe_list_ticket_types), so an agent can separate the two without opening either schema.

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?

The description tells the agent that ticket types are not part of this call and routes it to universe_list_ticket_types, which is a real alternative. It stops short of saying what to do when the id is unknown or when to prefer universe_list_events, so it is a clear usage context rather than a full when/when-not rule.

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

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

Annotations already declare readOnlyHint=true, so the trailing 'Read-only' is largely redundant. However, since there is no output schema, the enumeration of returned fields (including nested ticket items and their check-in state) is genuine behavioral disclosure that tells the agent what it gets back. Missing is any note on not-found behavior or permission requirements.

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?

One dense sentence: verb and key first, then the field inventory. Nothing is wasted and the identifier constraint is front-loaded.

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 correctly compensates by listing the returned structure, which is what an agent needs to decide whether to call it. Only the failure mode (unknown orderId) is unaddressed.

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?

Single parameter with 100% schema description coverage ('Order id.'). The description says 'by id' but adds no format, source, or derivation detail beyond the schema, so baseline 3 applies.

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 specific verb and resource with a clear scope qualifier: fetch ONE order by id, followed by the exact payload contents (buyer, state, cost breakdown, time slot, checkout answers, ticket items with check-in state). This implicitly separates it from universe_list_orders, which returns many. It stops short of naming the sibling explicitly, which keeps it from a 5.

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?

The 'by id' phrasing implies the lookup use case, but there is no explicit statement of when to prefer this over universe_list_orders or universe_list_attendees, and no prerequisites or error conditions mentioned. Usage is inferable but not stated.

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

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

The readOnlyHint annotation already declares the safety profile, so the trailing 'Read-only' adds nothing. However, because there is no output schema, describing that the result contains the signed-in user and their manageable host accounts is genuinely useful behavioral context about what comes back.

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?

Three short sentences, the identity/purpose statement is front-loaded, and each remaining sentence carries a distinct payload (workflow handoff, read-only note). Nothing to trim except the redundant read-only restatement.

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 parameters and no output schema, the description needs to sketch the return shape, and it does: user identity plus host accounts/team memberships. It could be slightly more explicit about what fields identify a host, but it is complete enough to call correctly.

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?

Zero parameters, so the baseline is 4. The description still adds value by explaining that a host id obtained here feeds into universe_list_events.

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 gives a specific verb and resource: it returns the signed-in user plus the host accounts they can manage (team memberships), which matches the 'Who am I' identity purpose. It is clearly distinct from the event/order/attendee listing siblings, though it never explicitly says 'this is the only identity tool, do not expect event data here'.

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?

It provides a concrete chaining instruction — take a host id from the result and pass it to universe_list_events — which tells the agent where this tool fits in a workflow. It stops short of stating when not to call it or what to do if the user has no host memberships.

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

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

Annotations already declare readOnlyHint=true, so safety is covered; the description adds the non-obvious fact that the result contains personal data, which matters for how an agent handles and surfaces output. It does not discuss pagination or result caps, though the schema documents limit/offset defaults.

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 compact sentences: purpose and returned fields first, then available filters, then data-sensitivity and read-only flags. No filler and nothing important buried.

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, listing name/email/ticket type/time slot/state/checkout answers in the description is exactly the compensation needed. Only pagination behavior and result-size expectations are left implicit, and those are handled by the schema.

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%, so limit, offset, match, states, eventId and timeSlotIds are already documented in the schema. The description restates the filter dimensions (state, text match, time slot) without adding syntax or matching behavior beyond the schema.

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 specific verb and resource ('List the attendees (ticket holders) of an event'), and clarifies what an attendee is versus an order, which separates it from universe_list_orders. It also enumerates the returned fields, so the agent knows exactly what data comes back.

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?

The description implies usage by saying filter by ticket state, text match or time slot, but it never states when to call this instead of universe_list_orders or universe_list_ticket_types. The 'ticket holders' framing hints at the boundary without making it explicit.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the trailing 'Read-only.' adds no new information. The genuinely additive content is the scoping rule (own events vs host events) and the field list returned, but nothing is said about pagination behavior, total counts, or whether the result is scoped by any other account boundary.

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 dense sentences, front-loaded with the resource and payload shape before the scoping rule. The only wasted text is the redundant 'Read-only.' clause, which duplicates the annotations.

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, listing the returned fields compensates well, and all five parameters are documented in the schema. What remains unaddressed for a paginated list tool is whether results include a total or next-page indicator and what ordering to expect.

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%, so the baseline is 3; the description earns an increment by explaining the hostId parameter's origin (ids come from universe_get_viewer) and the default no-hostId behavior, which the schema only says as 'Omit for your own events.' limit/offset/search/states add nothing beyond the schema, but they are already fully documented there.

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 specific verb and resource plus the returned field set (id, title, url, state, first date, venue, tickets sold), which is far more than a restatement of the name. It partially differentiates itself by pointing at universe_get_viewer for host ids, but does not distinguish itself from universe_get_event (single-event fetch) or the other list_* siblings.

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?

Gives an explicit conditional: omit hostId to list your own events, supply hostId to list that host account's events. It also names the upstream call that produces hostId. It stops short of stating when to use this versus universe_get_event or why a caller would need the state filter.

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

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

Beyond the readOnlyHint/openWorldHint annotations, it discloses that results contain buyer personal data — a material handling consideration not expressed anywhere in structured fields — and previews the returned fields. The 'Read-only' restatement adds nothing the annotation already says, which keeps it out of the top band.

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?

Three tight sentences, front-loaded with what is returned, then filters, then the PII caveat. No filler and nothing redundant beyond the minor 'Read-only' echo.

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 the return shape and flags PII; pagination is covered by the schema. It lacks detail on result ordering or behavior past the 100-item page cap, a small residual gap for a list tool.

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%, so eventId, limit, offset, match, states and updatedSince are already fully documented in the schema. The description only restates the three filter concepts without adding format or combination semantics, so the baseline of 3 applies.

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 specific verb and resource ('List the orders of an event') and enumerates the returned payload (buyer name/email, state, price breakdown, timestamps), which cleanly separates it from the singular universe_get_order sibling.

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?

The description spells out the available filter modes (state, text match, updated-since), giving clear context for when this tool fits. It never explicitly routes the agent to universe_get_order for a single order or to the sales/reporting siblings, so it stops short of full when-not guidance.

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

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

Annotations already declare readOnlyHint=true, and 'Read-only.' merely restates it rather than adding information. The valuable addition is the explicit list of returned fields (name, price, capacity, sold count, state, sales window), useful since there is no output schema, but there is no mention of pagination behavior or ordering.

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?

A single front-loaded sentence enumerating the resource and its fields, with zero waste. The trailing 'Read-only.' is redundant with the annotations and slightly dilutes an otherwise tight description.

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 returned fields, and the schema covers all parameters, so the agent has enough to invoke correctly. Only pagination/ordering behavior and output shape specifics are left unstated, which is minor for a list tool.

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 all four parameters (eventId, limit, offset, states) documented in the schema itself. The description adds only the framing that filtering is per-event, so baseline 3 is appropriate since the schema does the heavy lifting.

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 specific verb (List) and resource (ticket types/rates of an event) and enumerates the fields returned, so an agent knows exactly what it gets back. It is implicitly distinguishable from siblings like universe_list_events or universe_list_attendees, but no sibling is named to make the boundary 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. The phrase 'of an event' implies the requiredeventId context, but the agent must infer when this tool is preferable to e.g. universe_get_event or universe_list_time_slots.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the trailing "Read-only" merely restates structured data. The valuable addition is the enumerated return fields, but there is no mention of pagination behavior, default ordering, or what an empty result means for an event with no slots.

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 short sentences with zero waste: purpose and returned fields first, then the optional filter and safety note. Nothing is buried or redundant beyond the minor read-only restatement.

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 pre-announces the shape of each slot record. Pagination is left entirely to the schema, which covers it adequately, so the definition is nearly sufficient for an agent to call it correctly.

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 description coverage is 100%, so limit, offset, eventId, startAfter and startBefore are all documented in the schema itself. The description's only parameter content is the YYYY-MM-DD date-range filter, which duplicates the schema; baseline 3 applies.

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 specific verb+resource ("List the dates and time slots of an event") and enumerates the returned fields (start, end, capacity, tickets sold, state), which clearly separates it from siblings like universe_get_event or universe_list_events. It does not name a sibling explicitly, so it stops short of a 5.

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?

The description gives filter guidance ("Optionally filter by start date range") but never says when to choose this over universe_get_event or universe_list_ticket_types, nor any precondition beyond needing an eventId. Usage is implied by the resource name rather than stated.

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