DBpedia MCP has clear, well-structured tool definitions with explicit schemas and descriptions. All 4 tools are properly registered with inputSchema objects containing type, properties, and required fields. Descriptions are concise (50 - 180 chars) and action-oriented. However, parameter descriptions lack depth, most are 1 - 2 lines without guidance on valid ranges, formats, or error recovery. Output schemas are not documented, forcing LLMs to infer response structure. Error handling is present but generic ('DBpedia error: {status}') without recovery hints. No tool annotations (readOnlyHint, idempotentHint) despite all being read-only operations.

• Document output schemas for all tools. E.g., lookup returns {results: [{label, description, uri, type}], total_results: number}. sparql returns {format, body} or parsed JSON. resource returns {uri, triples: {predicate, object}[]}. abstract returns {label, lang, abstract, source, note}.
• Add enum constraints to format and type parameters. E.g., format: {enum: ['json', 'xml', 'csv', 'tsv'], description: 'Output format. JSON is fastest; CSV/TSV for bulk export.'} and type: {enum: ['Place', 'Person', 'Work'], description: 'DBpedia ontology type to filter results.'}
• Enhance error messages with recovery guidance. E.g., 'DBpedia Lookup error: 400, query may be malformed. Try a simpler label like "Einstein" instead of complex SPARQL syntax.' or 'Rate-limited (HTTP 429). Wait 60s before retrying or use sparql tool with a more specific query to reduce load.'
• Add readOnlyHint and idempotentHint annotations to all tool definitions to signal safety for retry and caching.
• Clarify resource tool's dual-mode input: 'uri: Full DBpedia resource URI (e.g. http://dbpedia.org/resource/Albert_Einstein) or human-readable label (e.g. Albert Einstein). Labels are auto-converted to URIs internally.'