We wish to answer the following question: what is the most appropriate language for describing the "contracts" that Maple routines offer? In this, we are seeking much more than types (which Maple does not have, at least statically), as these are not sufficiently expressive to capture what is going on. We also wish to study what is actually in Maple, rather than what should be there. Put another way, we do not expect to find that a type system like Aldor's or Axiom's would be especially helpful in explaining Maple. Our real goal is a mathematical description of the interfaces between routines. As such, the only current terminology flexible enough to encompass reality is that of contracts, by which we mean simply statements of complex properties (static as well as dynamic) in a sufficiently general logic. This works focuses mainly on the requirements analysis phase of this project: we perform automated analyses of the complete Maple library, to understand the kinds of contracts that are in actual use. We wish to know which kinds of theorems would need to be proved in order to formally analyze the types, effects, invariants, and contracts present in the current code base. As this is a monumental task, we describe what knowledge we have currently been able to extract from a very systematic approach to the problem.