Smsc Read

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

Annotations declare readOnlyHint=false, openWorldHint=true, destructiveHint=false; the description usefully adds that the tool needs no credentials, writes redacted local snapshots, and cannot send messages, move money, or change accounts — meaningful side-effect disclosure beyond the annotations. However it never explains why readOnlyHint is false or what exactly the snapshot write entails.

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 with little waste, but they are not front-loaded around a concrete action and key facts (what 'catalog' means, what gets snapshotted) are omitted rather than condensed.

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?

The tool has four undocumented parameters, an open-world non-read-only profile, and an output schema (which covers return values). The description still leaves the core operation semantics and snapshot side effect under-described for a tool with this much behavioral surface.

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 0% and the description barely compensates: 'catalog' obliquely hints at the operation default and 'redacted' hints at include_personal_data, but operation values, the free-form 'parameters' object, and include_text are left entirely undefined. With four parameters and no schema text, the description carries the burden and fails to.

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 names SMSC reads but the phrasing 'Discover allowed SMSC reads without credentials using catalog' is ambiguous — it is unclear whether the tool lists available operations, executes a read, or both. No sibling tool (smsc_history, smsc_cost_report, smsc_analytics) is referenced to distinguish this from them, so an agent cannot confidently pick it.

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?

'No sending, payments or account changes' rules out some scopes but gives no positive guidance on when to choose this instead of smsc_history or smsc_analytics. There are no prerequisites, no mention of what 'catalog' operation does, and no exclusions tied to alternatives.

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