The usefulness of the text that explains what an MCP tool does and when an agent should choose it. Good descriptions reduce wrong tool selection and argument errors. In practice, the best descriptions come from accurate OpenAPI summaries, then from careful enhancement when the spec is too sparse.
Expanded Definition
Tool Description Quality is the degree to which an MCP tool’s description accurately tells an AI agent what the tool does, what inputs it expects, and when it should be selected. In agentic systems, this is not cosmetic documentation; it is part of the control surface that shapes tool choice, argument construction, and failure handling. Strong descriptions reduce ambiguity, while weak or generic descriptions increase wrong-tool calls and malformed parameters.
In practice, the best descriptions often begin with an accurate OpenAPI summary and then are refined only where the spec is sparse. Definitions vary across vendors, but the operational goal is consistent: make the tool legible to the agent without inflating scope or promising capabilities the tool does not actually have. Guidance from the NIST Cybersecurity Framework 2.0 is relevant here because clear system documentation supports safer, more reliable control implementation.
The most common misapplication is writing marketing-style tool descriptions, which occurs when teams describe a tool in broad business language instead of precise operational terms.
Examples and Use Cases
Implementing tool descriptions rigorously often introduces governance overhead, requiring organisations to balance better agent reliability against the time needed to curate and review every tool entry.
- A billing reconciliation tool should say it matches invoice line items to ledger records, not simply “handles finance tasks,” so the agent selects it only for reconciliation workflows.
- An incident lookup tool should specify that it returns alert metadata and runbook links, helping the agent avoid using it for remediation steps it cannot perform.
- A secrets inventory tool should state whether it lists vault entries, detects exposed API keys, or both, because overly broad wording can cause the agent to request unsupported actions.
- A deployment validation tool should describe which environments it can inspect and which checks it performs, reducing argument errors when an agent targets the wrong cluster or pipeline stage.
- For broader NHI governance context, the Ultimate Guide to NHIs is useful because poor tool selection often becomes an identity and access problem when an agent is allowed to invoke the wrong capability with valid credentials.
OpenAPI summaries are often the best source of truth, and the NIST Cybersecurity Framework 2.0 reinforces why clear, current documentation matters for operational control.
Why It Matters in NHI Security
Tool Description Quality becomes a security issue when an autonomous agent can invoke privileged tools with the wrong intent, the wrong arguments, or both. If the description is vague, the agent may select a destructive administrative function when a read-only function was intended, or it may repeatedly retry malformed calls that expose sensitive data in logs. This is especially important for NHI-managed workflows because tool misuse can cascade into privilege abuse, overbroad access, or accidental secret exposure.
The risk is not theoretical. In the Ultimate Guide to NHIs, NHI Mgmt Group reports that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, which makes precise tool description even more important. Well-written descriptions are part of the guardrails that help agents stay within intended boundaries, complementing control frameworks such as the NIST Cybersecurity Framework 2.0.
Organisations typically encounter the consequences only after an agent has called the wrong tool in production, at which point Tool Description Quality becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Agentic tool selection reliability depends on clear tool descriptions and action boundaries. | |
| CSA MAESTRO | MAESTRO addresses agent tool-use governance and control over autonomous actions. | |
| NIST AI RMF | AI RMF emphasizes reliable, valid system behavior and documentation for AI-enabled workflows. | |
| NIST CSF 2.0 | GV.OV-01 | Governance and oversight require clear documentation of system capabilities and limits. |
| OWASP Non-Human Identity Top 10 | NHI-06 | NHI controls cover over-privileged automated access and misuse of service capabilities. |
Describe tools precisely so the agent chooses the right action and avoids unsafe or malformed calls.
