What questions should a service description answer, and why does a web service need one?

A service description is the "manual" that tells a programmer who offers the service, what it does, where to call it, and what it costs — without it the black box is unusable.

A web service deliberately hides its internals (the black-box principle), so a developer who wants to use it cannot just read the code. They need a service description instead — the documented contract that makes the service callable. Using the SMS example, a good description answers:

• Who offers it? -> the provider, e.g. "Firma X".
• What is offered? -> the interface, e.g. "send an SMS, with these parameters and result".
• Where is it? -> the endpoint, e.g. a URL like http://....
• Why / for what task? -> the purpose, usually described informally in prose.
• What does it cost? -> a price table, since many services are paid per call.

The first three ("Who / What / Where") are required to actually invoke the service; the last two are should/can — helpful but not strictly needed to make a call. Some descriptions are formal and machine-readable (so tooling can generate client code), but the cost and purpose are usually just human-readable text.