Samuelz® Operations

Heutigen Fokus lesen

get_today_focus

Read-onlyIdempotent

Read the current bounded work, alert and delivery pages and return at most three ranked next actions. Each action is one short plain-German sentence plus the next read capability. clearScore is 0 to 100 from that loaded open load. inboxZero is true only when every loaded page is complete and empty. The weekday streak counts only the current Europe/Berlin weekday in that clear state and does not reconstruct earlier days. A denied or unreadable alert page stays partial and is not inbox zero. When sales:read and operations:read are already granted, revenueCard is the single top open chance plus the path to the paid-revenue goal. It names renew_expired_offer or preview_payment_reminders but does not call them. If a list-price renewal is already prepared, approvalUrl is that existing owner page; do not call renew_expired_offer again. When policy:read and policy:write are already granted, policyCard is one pending owner rule, including the list-price standing send, and its url is the existing settings page. Opening that url does not confirm or send. When communications:read is already granted, reminderCard reads preview_payment_reminders and lists each planned reminder with amount, channel, slot and time, plus a short hint when the latest run failed. Reading it sends nothing. No writes, retries, acknowledgements or send authority.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_today_focus"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, and the description still adds substantive behavior: it defines clearScore, inboxZero, the Europe/Berlin weekday-streak rule, the partial-page rule for denied alerts, and the fact that no card triggers a write, retry or send. It also clarifies that cards name other capabilities without invoking them, which no annotation conveys.

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?

Purpose is front-loaded in the first sentence and each subsequent sentence documents a distinct output field, which is necessary given there is no output schema. It loses a little to repetition, since the no-side-effect guarantee is restated in four separate places ("does not call them", "does not confirm or send", "sends nothing", "No writes, retries, acknowledgements or send authority").

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the full burden of explaining return values and does so field by field: clearScore range and source, inboxZero preconditions, streak semantics, revenueCard, approvalUrl, policyCard and reminderCard contents. Permission preconditions for each card are stated, so an agent can interpret partial results correctly.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description spends its space on return semantics instead, which is the right allocation for a parameterless read.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a specific verb and resource set ("Read the current bounded work, alert and delivery pages") plus the output contract ("at most three ranked next actions"). That scope is distinguishable from sibling read tools like get_alert or list_alerts, which read a single page rather than composing a bounded daily focus.

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?

The description gives strong when-not rules for downstream tools ("do not call renew_expired_offer again", "Opening that url does not confirm or send"), but never states when an agent should pick this composite tool over get_alert or list_alerts. Usage for the tool itself is only implied by the word "current".

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

All Samuelz® Operations 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.

Resources

Need Help?